On 1/17/20 9:22 AM, Joseph Myers wrote:
On Fri, 17 Jan 2020, Joel Brobecker wrote:
The main goal of the limit is really to avoid accidents where someone
pushes something he shouldn't or something he didn't realize would
push so many commits. If the GCC repository is such that merges of
100 commits or more is going to be, if not routine, at least to be
expected, then perhaps increasing the limit would make sense.
Such merges are routine.
What I would do is wait a bit and see. This may become moot soon,
depending on the direction that we want to take for vendor/user branches
with respect to emails. I'm still trying to think this over...
Even disregarding user/vendor branches (and thus disregarding the question
of "new" commits resulting from rebasing, discussed in Iain's last comment
on <https://github.com/AdaCore/git-hooks/issues/9>), there is the matter
of shared refs/heads/devel/ branches (of which devel/c++-coroutines, the
one in the present discussion, is one).
Those branches are expected to have merges; the hooks prevent
non-fast-forward pushes to them. They are expected to live for a long
time, since it's large and complicated projects that tend to use such
branches. Merges may or may not be of more than 100 commits, depending on
how frequent they are. It's expected that several such branches will be
active at once. As shared projects, it's clear that commit mails for them
should go to gcc-cvs, even if we end up sending commit mails for user and
vendor branches to another list. And if there are say ten such branches
active at once, we don't want that to result in every commit to master
being mailed to gcc-cvs eleven times, once when originally committed and
once when merged to each such branch.
Indeed. Merge commits (where they are allowed) should produce a single
email about the merge itself, perhaps containing a list of commits.
Jason
