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