Re: "git commit -a" Doesn't Add New Files. Why?

[Junio C Hamano <gitster@pobox.com>]

"Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> writes:

> I have also not seen anyone really recommend using this option.

You mean "git commit -a"?

I actually do to anybody who is the kind of person who concentrates
on a single thing and completes that single thing well before moving
to another task.  It is a perfect tool for the job for such a way of
working.

Like when doing "git merge" or "git pull".  There, the "single
thing" that the person concentrates on is to complete the merge, and
with a reasonably written pre-commit hook to make sure there is no
leftover conflict markers [*], "git commit -a" to conclude a
conflicted merge is fairly safe.


[Footnote]

 * There should actually be pre-add hook to make it even less
   annoying.  After you see conflicts, "git add -u" happily adds the
   contents of the files in the working tree, with conflict markers
   still in them.  You can rely on the pre-commit hook that is
   triggered when you run "git commit" next time, and then use "git
   checkout -m" to recreate the conflicted higher-stage index
   entries for these paths, but if we had pre-add hook, we shouldn't
   have to know how to recover from such a mistake in the first
   place.