Junio C Hamano wrote: > Sam Vilain <sam.vilain@xxxxxxxxxxxxxxx> writes: > >> git-merge.sh was not running the commit hooks, so run them in the two >> places where we go to commit. >> >> Signed-off-by: Sam Vilain <sam.vilain@xxxxxxxxxxxxxxx> >> --- >> Not sure if it should call these or some specialist hooks, like >> git-am does. > > I suspect some people have pre-commit scripts that have been > meant to catch style errors for their own commits, and invoking > that on merge would wreak havoc --- there is not much you can do > if you want to get the work done by somebody else at that point. > Introducing a new pre-merge-commit hook would probably be safer; > if one wants to use the same check as one's pre-commit does, the > new hook in the repository can exec $GIT_DIR/hooks/pre-commit. > > The commit-msg hook I have no clue what people usually use it > for in the real world, but a merge commit message tends to be > quite different from the message you would give to your own > straight line commits, so custom reformatting rules people have > in commit-msg hook may not apply to merge commit messages. True. OTOH, if you commit with `git commit` after a merge which failed or was called with --no-commit, then it will call the commit hook. So those scripts would have to deal with that case anyway. So, should `git commit` detect it is committing a merge and call the merge-hooks, should we use the same hooks, or, should this be something like hooks/*-automerge ? Sam. - 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
