(A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and
(B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.
> (A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and
'git commit' commits everything that is currently in the index. 'git commit -a' commits all files currently tracked by git in their current state (if the version in the index and in the working directory differ, IIRC, the version in the working directory is used). It's the equivalent of a "git add FILE" for all tracked files with outstanding changes, right before a 'git commit'.
> (B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.
The index is meant to be the 'staging area' where you can pick and choose what you want to commit. See "git add -p FILE" for an example of more complex usage of the index than just picking and choosing which files to commit.
In general, think of 'git add' as your ability to promote changes from the working directory to the index, and 'git commit' as your ability to create a commit from the contents of the index.
How is that supposed to be a reasonable thing to do? Unlike my working directory, I can't build and test the contents of the index. To me, making a commit that I've never tested is somewhere between sloppy and negligent, so why is git encouraging me to do it?
I think that your issue is that you're thinking of a commit in git in the same way that you would think of a commit in svn. They are not the same. To commit in svn you are forced to push to the remote repo. Therefore you screw everybody up if your commit hoses things. In git, you can commit locally, and you are not even required to push those changes out. You could trash those commit without anyone ever knowing that you made them. You could make small atomic commits of small changes, and when the feature is ready to be pushed out to the 'canonical' repo, you could squash all of those small commits into one large commit, then push it out.
After some reading, it looks like it's actually possible to use git-checkout-index after an uncommitted merge to get the index contents out where I can test them. I'm still mystified that the preferred workflow is to blindly commit stuff that may not even run, which leaves you with the problem of somehow knowing which of the commits are actually useful points to roll back to or start new work from.
This is a bit of a late reply, but the reason it's committing everything that your colleague changed is that it's the definition of a merge commit.
I find that it's desirable to avoid merges to reduce the number of overall commits. To do this, do git pull --rebase instead of just git pull when your commit is rejected.
But:
(A) I see that it still commits everything, just like "commit -a", including all the files that I didn't change but that my colleague did in the branch that I'm pulling; and
(B) Why would "git add FILE; git commit" but "git commit FILE" not work? I bet it's something to do with the index.