"Kristoffer Haugsbakk" <kristofferhaugsbakk@xxxxxxxxxxxx> 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.