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
