On Wed, 15 Jan 2020, Jakub Jelinek wrote: > Hi! > > 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*. 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. > Is that what we want? I mean it doesn't scale well, even if everybody has > just a couple of personal branches + few vendor branches for all, if some of > them will be tracking master or release branches, if each such push > pushes all the commits again, there will be tens of thousands of mails. > And forcing everybody to squash all merge commits because of this is > undesirable. > Could we somehow detect merges from other branches (or say only master or > release branches) and don't send mails for those and send just a mail for > the merge commit? > Or, if that is not possible, disable gcc-cvs mail for vendor and private > branches altogether? -- Joseph S. Myers jos...@codesourcery.com
