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 jos...@codesourcery.com
