Re: Question about "git commit -a"

[Matthieu Moy <Matthieu.Moy@imag.fr>]

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