 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> OTOH, it's irritating to have to switch branches, click "merge
> revision...", select the branch I was just on, and then switch back
> again every single time I want to update one branch to match another. I
> imagine this is a limitation of the NetBeans, and if I used Git directly
> there would be a command to immediately update a branch without actually
> switching to it.
Another irritating thing is that creating a new branch does not /switch
to/ that branch. Just now I created a new branch, did a commit, and then
realised it updated the old branch, not the new one.
Fortunately, since a "branch" is simply a bookmark, all I need to do is
wind the new branch forward and wind the old one backwards.
Unfortunately, NetBeans can wind a branch forward, but cannot easily
wind backwards. Fortunately gitk can, but then NetBeans is confused,
until I switch branches back and forth a few times.
Damn that was irritating! LOL.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/04/2012 14:55, Invisible nous fit lire :
>
> Rather /more/ irritating is this: I made a commit, and then realised the
> description was wrong. (NetBeans defaults to using the exact same
> description as the previous commit - because that's SO USEFUL, right?)
> So I looked for the command to undo the last commit. Apparently there
> isn't one. I even found a question on Stack Overflow about it. Lots of
> people suggesting various complex workarounds to try to solve it, but
> nothing that says "just delete the last commit object!"
>
> Using the GUI, I was able to create a /new/ commit object identical to
> the old one but with a different description. The old commit object is
> still there though, showing up is a dangling branch. And I cannot find
> any way to get rid of it. It's all very annoying.
Trick learned from mercurial (hg): always work on a secondary repository
(not the "reference" one). Even better, a tertiary or deeper one.
If you did a wrong commit on the secondary, instead of pushing back
(well, its "git push" !) to the parent, just delete it and start over
(you might keep your delta first with some patch-compatible commands, so
as to reply them automatically: "hg diff" is very useful, i guess there
is some version for git too)
Basic of distributed revision control: as long as you did not export
your commit, you can hide your fault by just deleting the whole issue.
Once exported, you're doomed.
(Well, there is a few extension in hg to move/rewrite commits (even
regroup a few one), but they work only as far as the repositories which
know the details are erased from existence in order to never provide the
original pieces of information again)
As they say: Mount a scrap monkey!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Rather /more/ irritating is this: I made a commit, and then realised the
>> description was wrong. (NetBeans defaults to using the exact same
>> description as the previous commit - because that's SO USEFUL, right?)
>> So I looked for the command to undo the last commit. Apparently there
>> isn't one.
>
> Trick learned from mercurial (hg): always work on a secondary repository
> (not the "reference" one). Even better, a tertiary or deeper one.
> If you did a wrong commit on the secondary, instead of pushing back
> (well, its "git push" !) to the parent, just delete it and start over
> (you might keep your delta first with some patch-compatible commands, so
> as to reply them automatically: "hg diff" is very useful, i guess there
> is some version for git too)
Presumably you could just delete the .git subfolder and recopy... oh
wait, you're supposed to do git clone, aren't you? I wonder if that does
anything extra beyond just copying the files...
> Basic of distributed revision control: as long as you did not export
> your commit, you can hide your fault by just deleting the whole issue.
> Once exported, you're doomed.
Well, yes. Once it's public, it's part of history. And then if you want
to change it, you must rewrite history. Which isn't easy...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible escreveu:
> I gather a number of people do use Git, however.
the understatement of the year! well, since it's Andrew, perhaps just
of the month, we'll see...
It's now all around us. Plus, it's a cool word. I hope Gimp uses Git. :)
> All of this stuff gets /much/ easier to follow with gitk to show me WTF
> is actually happening. Unfortunately, Git seems to be a Unix
> application, meaning that you cannot install it without first installing
> a Unix emulator. The default installer binary seems to install MSYS,
> including Bash, Perl, Tk, and a whole bunch of other stuff. *sigh*
way to go!
You know git was written as a reverse engineering of the proprietary cvs
the Linux kernel project was using at some point, right?
--
a game sig: http://tinyurl.com/d3rxz9
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
> Presumably you could just delete the .git subfolder and recopy... oh
> wait, you're supposed to do git clone, aren't you? I wonder if that does
> anything extra beyond just copying the files...
Lesson learned a long time ago: never try to be smarter by going in the
backstage. Just play fair, respect the rules.
(of course, as you become a wizard, the limit of the backstage moves)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 08:38 PM, Le_Forgeron wrote:
> Le 10/04/2012 20:52, Orchid Win7 v1 nous fit lire :
>> Presumably you could just delete the .git subfolder and recopy... oh
>> wait, you're supposed to do git clone, aren't you? I wonder if that does
>> anything extra beyond just copying the files...
>
> Lesson learned a long time ago: never try to be smarter by going in the
> backstage. Just play fair, respect the rules.
> (of course, as you become a wizard, the limit of the backstage moves)
Indeed. This definitely works with Darcs. But I'm not sure if it works
for Git. I don't see why it wouldn't, but you never know...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 10/04/2012 08:05 PM, nemesis wrote:
> Invisible escreveu:
>> I gather a number of people do use Git, however.
>
> the understatement of the year!
It's only April.
> It's now all around us. Plus, it's a cool word. I hope Gimp uses Git. :)
A number of people use Git. A number of others use RCS, CVS, Subversion,
Mercurial, BitKeeper, Bazaar, Perforce, Visual Source Safe...
(Hell, there are even large projects which use Darcs. Though the main
one, GHC, recently switched to Git. It is unclear to me whether this is
because Darcs wasn't good enough, or just because all the would-be
contributers use Git not Darcs.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/2012 12:05, nemesis wrote:
> You know git was written as a reverse engineering of the proprietary cvs the
> Linux kernel project was using at some point, right?
Are you sure? I thought it was written to replace the reverse engineering of
the proprietary cvs?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 4/10/2012 5:55, Invisible wrote:
> How do we know the two implementations work the same way?)
Given thatall objects in the repository are looked up by the cryptographic
hash of their contents, the whole thing would fall apart if they weren't.
That said, the git book extensively documents the format of the repository,
which is completely trivial in practice. So... it's not hard.
> If I'm understanding this correctly, history is stored as commit objects,
Basically, yes.
Try this: http://book.git-scm.com/
It's excellent. (If it's the one I remember, which I think it is.)
> OTOH, it's irritating to have to switch branches, click "merge revision...",
> select the branch I was just on, and then switch back again every single
> time I want to update one branch to match another. I imagine this is a
> limitation of the NetBeans, and if I used Git directly there would be a
> command to immediately update a branch without actually switching to it.
Yes. Or you'd write a shell script. :-)
> One extremely irritating issue is that it's apparently impossible to create
> a commit object of a completely empty repository. So there can never be a
> branch where you start again from scratch. Every branch must always start
> out with /something/ in it. I suppose I could just create a dummy file to
> create commit 0, and then delete it again. But it's irritating.
Your commit has to point to a tree (aka directory). But you can start a
repository with an empty directory. If you manipulate things with the
lower-level commands, you can stick stuff in the repository without any
commits at all. (Which is how "commit" creates a commit - it puts the things
in the repository, then points a commit at them.)
> Rather /more/ irritating is this: I made a commit, and then realised the
> description was wrong. (NetBeans defaults to using the exact same
> description as the previous commit - because that's SO USEFUL, right?) So I
> looked for the command to undo the last commit. Apparently there isn't one.
You can only add to the repository, unless you prune it. But that doesn't
mean you need to see it.
http://stackoverflow.com/questions/927358/git-undo-last-commit
> I even found a question on Stack Overflow about it. Lots of people
> suggesting various complex workarounds to try to solve it, but nothing that
> says "just delete the last commit object!"
Uh, pretty much the first hit on google for "git revert commit."
> Using the GUI, I was able to create a /new/ commit object identical to the
> old one but with a different description. The old commit object is still
> there though, showing up is a dangling branch. And I cannot find any way to
> get rid of it. It's all very annoying.
"git gc" with the appropriate options to prune.
> (I could mutter something about how in Darcs this problem takes about 15
> seconds to fix... But what would that prove?)
It proves that Darcs isn't too worried about losing commits? ;-)
> One mildly niggling thing is that Git imposes an artificial order on things.
> Like, with Darcs, if I edit file X, and then make some completely unrelated
> change to file Y, then as far as Darcs is concerned, there is no ordering
> relation between these unrelated changes. But to Git, one commit is
> descended from the other, even though there's no logical relationship.
Git doesn't store changes. It stores snapshots. The order isn't so much
artificial as irrelevant to what you happen to be doing right now.
> Then again, shouldn't you be recording those
> two changes in the same commit?
Heavens no!
> The way Git does things does have the advantage that a situation like this
> just never happens. On the other hand, if I change file X on one branch and
> file Y on another branch (so the changes are /definitely/ unrelated), you
> still have to "merge" the changes to get back to a single branch.
Which makes sense. Commits are the fundamental unit of atomic change in git.
Now you have a snapshot with X changed, a different snapshot with Y changed,
and a snapshot with the two changes together. What could be easier?
--
Darren New, San Diego CA, USA (PST)
"Oh no! We're out of code juice!"
"Don't panic. There's beans and filters
in the cabinet."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> How do we know the two implementations work the same way?)
>
> Given thatall objects in the repository are looked up by the
> cryptographic hash of their contents, the whole thing would fall apart
> if they weren't.
>
> That said, the git book extensively documents the format of the
> repository, which is completely trivial in practice. So... it's not hard.
Well, you know, HTML is quite extensively documented. And yet, different
implementations don't interoperate too well...
>> OTOH, it's irritating to have to switch branches, click "merge
>> revision...",
>> select the branch I was just on, and then switch back again every single
>> time I want to update one branch to match another. I imagine this is a
>> limitation of the NetBeans, and if I used Git directly there would be a
>> command to immediately update a branch without actually switching to it.
>
> Yes. Or you'd write a shell script. :-)
It looks like "git reset" will do it, though I'm not completely sure on
the syntax. It doesn't really matter; NetBeans is still going to force
me to follow a 3-stage process.
>> One extremely irritating issue is that it's apparently impossible to
>> create a commit object of a completely empty repository.
>
> Your commit has to point to a tree (aka directory). But you can start a
> repository with an empty directory.
Mmm, OK.
>> Rather /more/ irritating is this: I made a commit, and then realised the
>> description was wrong.
>> So I
>> looked for the command to undo the last commit. Apparently there isn't
>> one.
>
> You can only add to the repository, unless you prune it.
I'm used to Darcs, where you can almost arbitrarily add, remove and
reorder changes. In particular, if you commit something, and then do "oh
bugger, I didn't mean to do that", it's one command to delete the
commit, which then makes all the changes it contained appear as "new" again.
> But that doesn't mean you need to see it.
>
> http://stackoverflow.com/questions/927358/git-undo-last-commit
Right... so... my options are:
1. Delete the last commit /and the changes it contained/. (Why would you
ever want to do this?)
2. Move the head back one commit, but not actually delete the commit.
3. Move the head back one commit, but not actually delete the commit,
and leave the changes in the staging area.
Nowhere is there an option that says "perform the exact inverse of what
I just told you to do".
>> I even found a question on Stack Overflow about it. Lots of people
>> suggesting various complex workarounds to try to solve it, but nothing
>> that says "just delete the last commit object!"
>
> Uh, pretty much the first hit on google for "git revert commit."
...which lists the three options above, none of which undo the commit.
It seems the best you can do is create a /new/ commit - which isn't much
help when the whole problem is that you have a commit that's labelled as
something it isn't, which is misleading and bound to cause confusion later.
> "git gc" with the appropriate options to prune.
That at least might work. (Somebody somewhere says prune only removes
dangling branches older than 2 weeks.) It's really quite frustrating how
all this documentation seems to be tutorials, blog posts and SO
questions. Isn't there a /reference manual/ somewhere??
>> (I could mutter something about how in Darcs this problem takes about 15
>> seconds to fix... But what would that prove?)
>
> It proves that Darcs isn't too worried about losing commits? ;-)
If your commit is wrong, you don't /want/ to keep it. :-P But seriously,
if I want to change something, why shouldn't I be able to change it? Git
has an "amend" command, it's just that it doesn't /amend/ the commit -
it creates a new one, but leaves the old one in place. The Darcs "amend"
command actually deletes the amended commit - you know, like what you'd
expect an amendment to consist of. :-P
I agree it's not a good idea to go back and start changing history from
2 years ago. But I don't see why you can't edit the last committed
change. That just seems like a silly limitation.
In a sense, Darcs /isn't/ that worried about losing commits. In Darcs, a
branch is a repository, and so to remove changes from a branch, you have
to delete commits. That's just how it works.
>> Then again, shouldn't you be recording those
>> two changes in the same commit?
>
> Heavens no!
You shouldn't group related changes together, no?
That's the other thing. With Darcs, I edit some files for a while, and
then say "commit this". It shows me each and every change, and asks if I
want to include that. And even though I've only got one set of changed
files, I can syphon off the changes and ground them into several
logically separate commits. Git can't seem to do that. If I want to
record some but not all changes, I have to manually construct the file
contents that I want committed. (And obviously NetBeans does nothing to
help with this.)
What I end up doing is just committing /everything/, because it's less
hassle. But then if I ever need to go back, I'd have to go in big giant
steps rather than small logical increments.
>> The way Git does things does have the advantage that a situation like
>> this
>> just never happens. On the other hand, if I change file X on one
>> branch and
>> file Y on another branch (so the changes are /definitely/ unrelated), you
>> still have to "merge" the changes to get back to a single branch.
>
> Which makes sense. Commits are the fundamental unit of atomic change in
> git. Now you have a snapshot with X changed, a different snapshot with Y
> changed, and a snapshot with the two changes together. What could be
> easier?
How about /not/ having to make a commit that records changes that I've
already committed? :-P
Actually, it would probably be easier if NetBeans would actually show
me, you know, /a history/, so I can see what's actually /happening/,
rather than just having to try to guess from the hashes which branches
contain what...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
