Junio C Hamano venit, vidit, dixit 06.09.2012 07:07: > Michael J Gruber <g...@drmicha.warpmail.net> 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.
That would be an option ;) Seriously, that would make the case where both hooks are the same even simpler, obviously. On the other hand it would make the other case more difficult. But, really, since non-automatic merges call pre-commit now, and that is probably to stay, catching those with a different (part of the pre-commit) hook will stay difficult anyways. So the question is really more whether we prefer to bloat the config space or the name space by this. Either works for me, and if we don't change the current behaviour (pre-commit-hook resp. no hook for non-automatic merges resp. automatic merges) the config option is probably less confusing. Michael -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
