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

[Eli Zaretskii]

> From: Noam Postavsky <address@hidden>
> Date: Sat, 29 Apr 2017 15:54:41 -0400
> Cc: Paul Eggert <address@hidden>, martin rudalics <address@hidden>, 
>       Emacs developers <address@hidden>, Andreas Schwab <address@hidden>, 
> Yuri Khan <address@hidden>
> 
> On Sat, Apr 29, 2017 at 3:15 PM, Eli Zaretskii <address@hidden> wrote:
> >> > Since git only runs the hooks on the merged changes when you pass
> >> > --no-commit to 'git merge', defaulting to non-blind merge doesn't
> >> > really work anyway.
> >>
> >> Thanks for looking into this. I guess I'll have to rethink how I merge.
> >
> > Not sure it matters in the context of this discussion, but please keep
> > in mind that "git cherry-pick" also merges.
> 
> My intuition is that getting a commit hook failure from the commit
> being cherry picked will be less confusing than getting hook failures
> from one of the  many commits being merged from a branch, so I don't
> think it's worth updating the hook to avoid this case.

I don't think I agree.  In fact, I think many users will not even
realize that cherry-pick merges, and will be surprised.

> 'git cherry-pick' does have the same issue as 'git merge': it won't
> rerun the commit hook, unless '--no-commit' is passed

Too bad.  I wish this could be fixed as well.