Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers <joseph@codesourcery.com>]

On Thu, 16 Jan 2020, Joel Brobecker wrote:

> 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.

The approach used by post-receive-email is to send a summary email but 
without resending the already-sent commits.  That seems appropriate to me.

> 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.

A summary email just listing the commits merged seems much better than 
sending email maybe dozens of times for every commit to master.

> 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.

I think it's desirable for development that *happens on* the personal and 
vendor branches to be visible in gcc-cvs - that is different from things 
getting merged into them.

Likewise for the refs/heads/devel/* development branches - 
non-fast-forward pushes are not permitted there, but such branches can 
expect to have lots of merges from master, and it's the actual development 
taking place *on* the branches - the new commits - that is of interest to 
see on gcc-cvs, not the merging of existing commits.

-- 
Joseph S. Myers
joseph@codesourcery.com