Re: Question about "git commit -a"

From: Matthieu Moy <matthieu.moy@imag.fr>
Date: Oct 5, 2007, 16:33 UTC
Message-ID: <vpq641led25.fsf@bauges.imag.fr>
In-Reply-To: <1191599763.7117.18.camel@hinata.boston.redhat.com>

Kristian Høgsberg <krh@redhat.com> writes:

> I understand why people like staging and commit without -a, seeing how
> it's faster and all,

Actually, commit without -a is not much faster, since it runs "status" internally, to show it to the user when launching the editor. So, it still checks for changes in the working tree.

> but I have a serious problem with this practice that I haven't seen
> brought up on the list. How do you know what you commit actually
> works or even compiles?

That's a general problem with partial commits, and that's why I personnaly don't like partial commits in general ($scm commit file1 file2 has the same problem, \forall $scm).

To me, the right approach to partial commit is to stash the unwanted changes, test, commit, and unstash.

(side note: it would be cool to have a "git stash --unstaged" command, to put the unstaged changes aside, and match the tree to the index. A good approximation for that is:

$ git stash # put all aside $ git reset --mixed stash^2 # get back what the index used to be $ git add -u # and put it back into the index. )

*But*, the cool thing with git is that you can view rather easily not only what you're about to commit (git diff --cached), but also what you're about _not_ to commit (git diff). So, if the unstaged changes are trivial enough, it can be OK (for example, Linus changes the linux version in a Makefile a few commits before the release, and doesn't add it to the index, to keep it as a reminder).

But I agree with your that splitting a huge patch into smaller ones using just the index is bad practice, except if you intend to come back to each commit and test it later.

-- 
Matthieu