Re: Question about "git commit -a"

["Kristian Høgsberg" <krh@redhat.com>]

> I just don't do 'git commit -a' for the same reason I don't do
> 'git commit -m', really. It tends to be habit-forming, and bisect
> has saved my arse enough times for me to *want* my changes to be
> small and isolated. Debugging a 5-line patch is so much more pleasant
> than debugging a 30k-lines one that spans over several different files.

I understand why people like staging and commit without -a, seeing how
it's faster and all, 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?  The reason that I almost
exclusively use -a with commit is that I want to know that what I just
compiled and tested is what I will be committing.  I don't want to just
commit half the files in my working copy, I want to make sure that the
exact state of my project that I just compiled and tested is what gets
into version controlled history.

git commit -a isn't sloppy to me - eye balling some subset of your
working copy and committing that under the assumption that you don't
make mistakes and don't need to compile what you commit... that is
sloppy.

Kristian