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