Re: git pre-commit hook for merges (WAS: master has switched from Automake to GNU Make)

[Noam Postavsky <npostavs@users.sourceforge.net>]

On Wed, Apr 12, 2017 at 2:26 PM, Paul Eggert <eggert@cs.ucla.edu> wrote:

> When I do a merge, though, I'd rather see problems from the other side (so
> that I can fix them).

I would note that a usual 'git merge' skips the pre-commit hook
entirely, unless the commit is delayed somehow. That is, the hook only
triggers if $EDITOR can't run in the current terminal, there is a
merge conflict, or the --no-commit option is given. 'git rebase' runs
the hook for the other side's changes at all. I think this is why
there was so much confusion over this, Martin hits this frequently
because he runs 'git merge' in a *shell* buffer, whereas most other
people hit it very rarely or not at all.

> How about an environment variable that captures the
> user's preference?

That sounds okay. I wonder if it would be more convenient to control
this by a ./configure option instead though.

>> +    head=$(cat "$GIT_DIR"/MERGE_HEAD)
>
> This won't work if MERGE_HEAD file contains more than one entry, which can
> happen when doing a 3- or more-way merge. How about the attached (untested)
> patch instead? It behaves the way that you suggested, when doing a 2-way
> merge and when the GIT_MERGE_BLINDLY environment variable is set to 'true'.
> Offhand I don't see a way of supporting 3- or more-way merges easily, so
> this patch punts and ignores GIT_MERGE_BLINDLY when doing fancier merges.

Ah right, forgot about multiway-merges. Punting should be fine, I'm
sure anyone trying an octopus merge should have enough git expertise
to handle some commit hook errors.