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

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 21, 2017, 01:10 UTC
Message-ID: <xmqqy3p8n9fe.fsf@gitster.mtv.corp.google.com>
In-Reply-To: <CAGZ79kaN4nKwGXq9t+Lv9e4X6qkBUAj4S8gofrNj3VZYw1sv+w@mail.gmail.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.