Re: [PATCHv3] builtin/merge: honor commit-msg hook for merges

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

Stefan Beller <sbeller@google.com> writes:

> I'll send a patch fixing the docs, though with this thought, maybe we need
> to fix other commands, that produce commits as well?
> (git revert, others?)

I do not think "commands that create commits" is not a good
criteria.  "git notes" and "git stash" would (internally) create a
commit while recording a new change, but you obvously would not want
these hooks to kick in.

A command that can stop in the middle and to which running "git
commit" is how the end-user concludes the operation would be a
candidate.  "git merge X", "git cherry-pick A", and "git cherry-pick
A..B" may be good candidates.

For "rebase" and others that have the "convenience --continue"
option that make a commit before continuing, I would think that we
should treat these as invoking "git commit".  That is, when these
commands stop and you resolve the conflict in the index and in the
working tree, the next "git $cmd --continue" you type is merely a
way to let you be lazy.  You'd be typing "git commit && git $cmd
--continue" if you were to refuse the lazy convenience option and
want to spell out what you are doing explicitly, and you'd get the
same result as you'd get from just "git $cmd --continue" if you did
so.

On the other hand, "git am" is not a candidate.  You never use "git
commit" to mark that you are done, even if you refuse to use the
lazy convenience option and spell out what you are doing explicitly.