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

[Jakub Jelinek <jakub at redhat dot com>]

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.

> I think there's a similar issue not just for merges but for 
> non-fast-forward pushes as well.  As a glibc example, consider 
> <https://sourceware.org/ml/glibc-cvs/2019-q4/msg00666.html> and the long 
> series of subsequent mails in the glibc-cvs archives.  It's correct that 
> the five or so rebased patches on the branch got mailed out again.  It's 
> *not* desirable that the 50 or so patches that were already on master, 
> that the branch got rebased on top of, got mailed out again.

	Jakub