On 16/01/2020 14:11, Jakub Jelinek wrote:
On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:
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.
Couldn't it be then per-branch setting, whether to mail even commits
that aren't new to the repository or not (like I understood it is already
possible to decide per-branch whether to send mails at all)?
E.g. for GCC, I'd certainly like to see mails for all commits on the
trunk and release branches (but we don't allow merge commits on them
anyway), and for other branches (personal, vendor, devel) I think mailing
only about new commits not already in the repository would be better over
not mailing at all.
Jakub
The alternative I suggested to Joseph yesterday was a separate mailing
list for all the personal and vendor commits. But I think that would
need a change to the hooks infrastructure.
R.
