limit on emails for merge commits.

limit on emails for merge commits.

[Iain Sandoe]

I have a merge commit to devel/c++-coroutines, which is intended to refect  
the state at the point of commit to trunk.

However, I cannot push that commit because:

remote: *** This update introduces too many new commits (284), which would
remote: *** trigger as many emails, exceeding the current limit (100).
remote: *** Contact your repository adminstrator if you really meant
remote: *** to generate this many commit emails.
remote: error: hook declined to update refs/heads/devel/c++-coroutines
To git+ssh://gcc.gnu.org/git/gcc.git
  ! [remote rejected]         devel/c++-coroutines -> devel/c++-coroutines (hook declined)

in fact, I usually merged trunk into the branch weekly - this one got  
slightly delayed because it was intended to be the final one.

284 isn’t a lot of trunk commits for an interval between merges into a  
devel branch, so this seems likely to fire quite often.

——

So I know that the policy is under review (and agree, from my PoV, that  
something that represents these in a similar way to the SVN single mail  
containing all the changes is probably optimum).

However, right now I’m stuck - and really want to get a short-term  
resolution so that i can complete the merge of coroutines onto trunk.

I guess I could do a squashed merge from trunk - presumably, that would  
only generate 1 email?

cheers
Iain

Re: limit on emails for merge commits.

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1232 bytes --]

On Fri, 17 Jan 2020, Iain Sandoe wrote:

> So I know that the policy is under review (and agree, from my PoV, that
> something that represents these in a similar way to the SVN single mail
> containing all the changes is probably optimum).
> 
> However, right now I’m stuck - and really want to get a short-term resolution
> so that i can complete the merge of coroutines onto trunk.
> 
> I guess I could do a squashed merge from trunk - presumably, that would only
> generate 1 email?

You should include Joel on such questions as the expert on the hooks.

I don't know whether there's something to put in the commit message to say 
"allow this merge of more than 100 commits".  I don't think a squashed 
merge is the right workaround, supposing you do want the git ancestry 
information to reflect what got merged.  The simple workaround is to do 
three successive merges, each of under 100 commits and each pushed 
separately.  Alternatively, you could check out refs/meta/config, push a 
change that either increases hooks.max-commit-emails or sets 
hooks.no-emails to prevent mails for this branch, then push the merge, 
then push a reversion of the change to refs/meta/config.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: limit on emails for merge commits.

[Joel Brobecker]

Hello,

> You should include Joel on such questions as the expert on the hooks.
> 
> I don't know whether there's something to put in the commit message to say 
> "allow this merge of more than 100 commits".  I don't think a squashed 
> merge is the right workaround, supposing you do want the git ancestry 
> information to reflect what got merged.  The simple workaround is to do 
> three successive merges, each of under 100 commits and each pushed 
> separately.  Alternatively, you could check out refs/meta/config, push a 
> change that either increases hooks.max-commit-emails or sets 
> hooks.no-emails to prevent mails for this branch, then push the merge, 
> then push a reversion of the change to refs/meta/config.

Joseph pretty much nailed it in terms of options.

-- 
Joel

Re: limit on emails for merge commits.

[Iain Sandoe]

Hi Folks,

Joel Brobecker <brobecker@adacore.com> wrote:


>> You should include Joel on such questions as the expert on the hooks.
>>
>> I don't know whether there's something to put in the commit message to say
>> "allow this merge of more than 100 commits".  I don't think a squashed
>> merge is the right workaround, supposing you do want the git ancestry
>> information to reflect what got merged.  The simple workaround is to do
>> three successive merges, each of under 100 commits and each pushed
>> separately.  Alternatively, you could check out refs/meta/config, push a
>> change that either increases hooks.max-commit-emails or sets
>> hooks.no-emails to prevent mails for this branch, then push the merge,
>> then push a reversion of the change to refs/meta/config.
>
> Joseph pretty much nailed it in terms of options.

Yeah - I agree.

I didn’t do the squash merge because I don’t want to lose the ancestor  
history
on the branch.

For the sake of separating the process of merging coroutines from our general
git policies, I am going to use several smaller merges - this is a simple and
transparent workaround.

I think editing the hooks would be less transparent and doesn’t solve the
‘spamming the commits ML’ any better.

---

As I noted, 100 commits to master is a small number, so I expect this problem
to fire almost every time someone does a merge of master to a devel or user
branch (unless they have the habit of doing that almost daily, which I  
doubt for
most).

thanks
Iain

Re: limit on emails for merge commits.

[Joel Brobecker]

Hi Ian,

> As I noted, 100 commits to master is a small number, so I expect this problem
> to fire almost every time someone does a merge of master to a devel or user
> branch (unless they have the habit of doing that almost daily, which I doubt
> for
> most).

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.

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

-- 
Joel

Re: limit on emails for merge commits.

[Joseph Myers]

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

Re: limit on emails for merge commits.

[Richard Biener]

On January 17, 2020 3:22:11 PM GMT+01:00, Joseph Myers <joseph@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. 

Re: limit on emails for merge commits.

[Joseph Myers]

On Fri, 17 Jan 2020, Richard Biener wrote:

> We also make sure (?) to not make them show up in bugzilla, right?

That's already done; the email-to-bugzilla-filtered script only passes 
commits to master and release branches (i.e., pushes that update those 
refs) to Bugzilla.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: limit on emails for merge commits.

[Jason Merrill]

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