builtin/merge: honor commit-msg hook for merges
commitf8b863598c991a5441d97e5dc59af8968ea37e37
authorStefan Beller <sbeller@google.com>
Thu, 7 Sep 2017 22:04:29 +0000 (7 15:04 -0700)
committerJunio C Hamano <gitster@pobox.com>
Fri, 8 Sep 2017 00:52:11 +0000 (8 09:52 +0900)
tree36713686723a754fc8bcd2bdd7d92115c29b985c
parent3ec7d702a89c647ddf42a59bc3539361367de9d5
builtin/merge: honor commit-msg hook for merges

Similar to 65969d43d1 (merge: honor prepare-commit-msg hook, 2011-02-14)
merge should also honor the commit-msg hook: When a merge is stopped due
to conflicts or --no-commit, the subsequent commit calls the commit-msg
hook.  However, it is not called after a clean merge. Fix this
inconsistency by invoking the hook after clean merges as well.

This change is motivated by Gerrit's commit-msg hook to install a ChangeId
trailer into the commit message. Without such a ChangeId, Gerrit refuses
to accept any commit by default, such that the inconsistency of (not)
running the commit-msg hook between commit and merge leads to confusion
and might block people from getting their work done.

As the githooks man page is very vocal about the possibility of skipping
the commit-msg hook via the --no-verify option, implement the option
in merge, too.

'git merge --continue' is currently implemented as calling cmd_commit
with no further arguments. This works for most other merge related options,
such as demonstrated via the --allow-unrelated-histories flag in the
test. The --no-verify option however is not remembered across invocations
of git-merge. Originally the author assumed an alternative in which the
'git merge --continue' command accepts the --no-verify flag, but that
opens up the discussion which flags are allows to the continued merge
command and which must be given in the first invocation.

Signed-off-by: Stefan Beller <sbeller@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
builtin/merge.c
t/t7504-commit-msg-hook.sh