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: Joel Brobecker <brobecker at adacore dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: Jakub Jelinek <jakub at redhat dot com>, "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>, gcc at gcc dot gnu dot org
- Date: Thu, 16 Jan 2020 12:40:02 +0100
- Subject: Re: gcc-cvs mails for personal/vendor branches for merge commits
- References: <20200115141617.GS10088@tucnak> <alpine.DEB.firstname.lastname@example.org>
> 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*.
We used to have that kind of behavior, and found that this was causing
problems. The main problem is when you are merging a branch for which
for which a no-email policy applies to a branch for which the normal
emails are to be sent. This happens for instance when people used
development branches that they had silenced so as to avoid spamming
people. And because they have been rebasing their branch regularly,
the "merge" ended up being a fast-forward. And because it was a fast
forward, the hooks saw that the commits were already known to the
repository, and no email was sent at all for those new commits.
Beyond this specific issue of users being surprised about the missing
emails, we thought about it more, and it seemed logical that we would
want a trace for each branch a commit makes it to. It's an essential
element of being able to track where a given commit was applied.
> 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.
At heart, it is really the same issue. New commits were brought into
this branch, and thus if email notification is enabled for that branch,
then those commits should trigger emails for their own as well.
Typically, branches were non-fast-forward changes are allowed are
branches that are personal and not shared. In those instances,
the typical setup is to disable emails on those development branches.
It sounds to me like turning emails off for branches that can
do non-fast-forward is the better solution here.