Re: [tlug] Great Git resources

["Stephen J. Turnbull" <stephen@example.com>]

Darren Cook writes:

 > Git has gitg, gitk, git-gui, etc. and they are all very similar and all
 > pointless. Well, some of them will draw pretty pictures of your merge
 > graphs. But for seeing what you've changed, for doing commmits, etc.
 > they are useless.

I use gitk all the time for seeing what I've changed.  I grant it's
not very useful if you have a really big commit, but I almost never
do.

I tried git-gui briefly (since I advocate git I should know something
about its tools.  It seemed like a reasonable gui for constructing and
performing commits, and even doing merges.  But I'm not an expert on
it -- I use XEmacs or the command line in real work.

What's wrong with git-gui?

 > [1]: I wouldn't mind if the git meaning of "revert" fitted better. But
 > it actually means "I'd like to alter one of earlier commits". "git
 > recommit" or "git fixcommit" would have made more sense.

No, that's "git commit --amend".

Why "git revert" is different, well, I suspect that Linus took
"checkout" from CVS (and I think it makes perfect sense).  Since he
now had a command that does everything that most VCSes revert command
does, he decided that revert should apply to commits, not to the
working file set.  It makes perfect sense if you think in terms of
"reverting an unwanted commit", which is something that git users do a
lot because making a commit is cheap to do and cheap to undo.  Better
to save your mistakes in case they aren't.  Basically, in git you
should rarely be doing anything with uncommitted changes in your tree
except preparing to commit them.

In general, I find other VCSes (including Mercurial, Bazaar, and
Subversion) to be rather obtuse when it comes to branching and
merging (which I do a lot, even in a private project).  Only git and
Darcs do these operations in a way I find intuitive (although they are
completely different in how they implement them).