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

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

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.