Orgad Shaneh <orgads@xxxxxxxxx> writes: >> Hmm. This is not very convincing to me, as >> >> - if you call commit-msg in `git merge` now, why not `prepare-commit-msg`? > > prepare-commit-msg is already called, a few lines above this addition. I do not see such call in contrib/example/git-merge.sh; could it be a recent bug that it calls it? >> - a merge is a different beast from a simple commit. That is why we have >> two different commands for them. A hook to edit the merge message may >> need to know the *second* parent commit, too, for example to generate >> a diffstat, or to add information about changes in an "evil commit". > > That is correct for a post-merge hook. Why should *message validation* differ > between simple and merge commit? Have you seen a typical merge commit message? They certainly look different to me and different rules would apply. >> - if Gerrit is the intended user, would it not make more sense to >> introduce a new hook, e.g. `merge-msg` (and `prepare-merge-msg`), as you >> have to teach Gerrit a new trick anyway? > > Why is that new? Every commit in gerrit has a Change-Id footer, which is > generated by commit-msg hook. Hmm, I didn't know Gerrit gave Change-ID to merges. In any case, I would think this is completely new. Without this change, commit-msg was not called for merges, so Gerrit wouldn't have added Change-ID to merges with that mechanism. A new merge-msg hook would make more sense, if we were making any change. I do not want to get yelled at by those who wrote their commit-msg hooks long time ago and have happily been using them that updated Git started calling them for their merges where their validation logic for their single-parent commit do not apply at all. -- 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