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: Jakub Jelinek <jakub at redhat dot com>
- To: Joseph Myers <joseph at codesourcery 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 16:01:09 +0100
- Subject: Re: gcc-cvs mails for personal/vendor branches for merge commits
- References: <20200115141617.GS10088@tucnak> <alpine.DEB.firstname.lastname@example.org>
- Reply-to: 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.