gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

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
joseph@codesourcery.com