On Wed, 15 Jan 2020, Jakub Jelinek wrote: > On Wed, Jan 15, 2020 at 02:56:45PM +0000, Joseph Myers wrote: > > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch > > > a simple > > > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3 > > > git push origin > > > redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch > > > which merged in just a few hours from trunk, but that resulted in > > > 20 separate mails to gcc-cvs ml. > > > > Joel, this is definitely a question for you; it's beyond my expertise in > > the working of the hooks. The issue is that when a merge commit is > > pushed, we only want mails for commits that are new *to the repository* - > > not those that are already in the repository (accessible from some other > > ref before the ref update being processed by the hook comes into effect), > > but are new *to the branch*. > > Yeah. For release branches I think we want mails for all changes, but > then we don't allow merge commits there; for cherry-picked patches e.g. from > trunk to release branches we should still send mail.
A cherry-picked commit has a different commit id from the original, so is a new commit in the repository. Note: the old post-receive-email example hook shipped with git does the "only commits new to the repository" thing. Its form of the logic (function show_new_revisions) appears to be "only commits not reachable from any ref in refs/heads", which it converts into a list of negated revisions to pass to git rev-list when computing the new commits to show. -- Joseph S. Myers jos...@codesourcery.com
