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