On January 17, 2020 3:22:11 PM GMT+01:00, Joseph Myers <jos...@codesourcery.com> 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.
We also make sure (?) to not make them show up in bugzilla, right? Richard.
