'git diff' (also hopefully obvious)
Except it's not, since it'll output different things depending on whether you have staged anything or not.
This behavior is sometimes useful, but hardly obvious. Many aspects of git are like this, and it's frustrating, speaking as someone who slowly came around to git and now likes it quite a bit and would recommend it, to see its advocates forget or try to talk around just how difficult it is to learn. (1.5 and 1.6 may have improvements, but the claim that git's now roughly as easy to learn as hg or bzr, especially without understanding its internals, is absurd.)
This is precisely why I suggested doing a commit after every sequence of adds and removes.
but that is (one of) the point of the index. that you can build of to a clean changeset to commit. hg mq is easier i think.
Re:Why Git is Better Than X
by nostrademons on Monday December 01, 2008 @05:50PM
(#382261)
'git mv' for moving files, and I'm overly dependent upon 'git status' for checking what's changed.
Agreed on both points, although 'git mv' is optional. As long as the old file is 'git rm'ed and the new file is 'git add'ed in the same commit, git detects the rename quite reliably.
mv is just sugar, though, you can easily copy the file using unix "cp" and delete/add to get the same result. Git does not track renames.
Branching is a killer feature, as is clean history management, as is the index, and when you find yourself wishing more control over what happens to your source code, wishing for freedom to experiment, all these tools will be there waiting for you.