This is the mail archive of the
mailing list for the GCC project.
Re: gcc-cvs mails for personal/vendor branches for merge commits
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, <gcc at gcc dot gnu dot org>, Joel Brobecker <brobecker at adacore dot com>
- Date: Wed, 15 Jan 2020 14:56:45 +0000
- Subject: Re: gcc-cvs mails for personal/vendor branches for merge commits
- Ironport-sdr: Ch/0I0m7PJcfz6zwYTzV6nVZotRzyErRQKTpH3e8n4+0WUKONvOtRbg8USVtPKdkUlX0l83WOO 19fA8zNn6TjdD7Om4UCyWbNUsVzsjekdG/EEFf5OgyMkbII2EIZHNsHtrrnisYUyd+Ar3SUBvb j4fF75IwMT2EaTAtt9rnaHHbSqq7+7oh03FI3+gYPeNRTx6yajSxLUkXh70IUDpqsh8+5NBdqM phcwiMruMBy+VlWCeGiXcKMCjkU3fuZsH1l7UFlpiJjjbqyiamyc+qd6g6H1Ul/V0VNvC6VXGm DYg=
- Ironport-sdr: kZ2Php7DwiUDF9D6BEUa1aVXz60+a55rGJ5646aKK3usLLxOXBznHr/q8ktBD1BhCE8Y/h+QNo 04dWMK1gwwZSqvwFr08xbigpYGXvcTAKfqk3QDb3g7CJInTQonljpR+qTQzhvAoWmMmnWlo4wi ww4+oxEplkdMJlXHuSC3KYL4tQ6gjna+PKFmv4y9PTyFj4WXDLe6NOPhoMqzvOGSOXV9zJcv1d yL4GM7HKCwS7Z/CFnO1vxrzDIKdDn7NIGDPr3yV5bJcUAwE0Ys5R2rDvhutgBvfpdUNJrmhvEh Tik=
- References: <20200115141617.GS10088@tucnak>
On Wed, 15 Jan 2020, Jakub Jelinek 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*.
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
> 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