Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > The pre-commit hook is often used to ensure certain properties of each > comitted tree like formatting or coding standards, validity (lint/make) > or code quality (make test). But merges introduce new commits unless > they are fast forwards, and therefore they can break these properties > because the pre-commit hook is not run by "git merge". > > Introduce a pre-merge hook which works for (non ff, automatic) merges > like pre-commit does for commits. Typically this will just call the > pre-commit hook (like in the sample hook), but it does not need to. When your merge asks for a help from you to resolve conflict, you conclude with "git commit", and at that point, pre-commit hook will have a chance to reject it, presumably. That means for any project that wants to audit a merge via hook, their pre-commit hook MUST be prepared to look at and judge a merge. Given that, is a separate hook that "can just call the pre-commit but does not need to" really needed and useful? I admit that I haven't thought things through, but adding a boolean "merge.usePreCommitHook" smells like a more appropriate approach to me. I dunno. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html