gcc-cvs mails for personal/vendor branches for merge commits

gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

Hi!

As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
a simple
git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
which merged in just a few hours from trunk, but that resulted in
20 separate mails to gcc-cvs ml.
Is that what we want?  I mean it doesn't scale well, even if everybody has
just a couple of personal branches + few vendor branches for all, if some of
them will be tracking master or release branches, if each such push
pushes all the commits again, there will be tens of thousands of mails.
And forcing everybody to squash all merge commits because of this is
undesirable.
Could we somehow detect merges from other branches (or say only master or
release branches) and don't send mails for those and send just a mail for
the merge commit?
Or, if that is not possible, disable gcc-cvs mail for vendor and private
branches altogether?

	Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jakub Jelinek wrote:

> Hi!
> 
> As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> a simple
> git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> which merged in just a few hours from trunk, but that resulted in
> 20 separate mails to gcc-cvs ml.

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

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.

> Is that what we want?  I mean it doesn't scale well, even if everybody has
> just a couple of personal branches + few vendor branches for all, if some of
> them will be tracking master or release branches, if each such push
> pushes all the commits again, there will be tens of thousands of mails.
> And forcing everybody to squash all merge commits because of this is
> undesirable.
> Could we somehow detect merges from other branches (or say only master or
> release branches) and don't send mails for those and send just a mail for
> the merge commit?
> Or, if that is not possible, disable gcc-cvs mail for vendor and private
> branches altogether?

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Wed, Jan 15, 2020 at 02:56:45PM +0000, Joseph Myers wrote:
> > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > a simple
> > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > which merged in just a few hours from trunk, but that resulted in
> > 20 separate mails to gcc-cvs ml.
> 
> 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*.

Yeah.  For release branches I think we want mails for all changes, but
then we don't allow merge commits there; for cherry-picked patches e.g. from
trunk to release branches we should still send mail.

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

	Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jakub Jelinek wrote:

> On Wed, Jan 15, 2020 at 02:56:45PM +0000, Joseph Myers wrote:
> > > As I said on IRC, I have done on our vendor branch redhat/gcc-10-branch
> > > a simple
> > > git merge r10-5981-ga52d93219c63d38fa9a97d0eb727e7fcc935e9b3
> > > git push origin redhat/gcc-10-branch:refs/vendors/redhat/heads/gcc-10-branch
> > > which merged in just a few hours from trunk, but that resulted in
> > > 20 separate mails to gcc-cvs ml.
> > 
> > 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*.
> 
> Yeah.  For release branches I think we want mails for all changes, but
> then we don't allow merge commits there; for cherry-picked patches e.g. from
> trunk to release branches we should still send mail.

A cherry-picked commit has a different commit id from the original, so is 
a new commit in the repository.

Note: the old post-receive-email example hook shipped with git does the 
"only commits new to the repository" thing.  Its form of the logic 
(function show_new_revisions) appears to be "only commits not reachable 
from any ref in refs/heads", which it converts into a list of negated 
revisions to pass to git rev-list when computing the new commits to show.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 9:56 AM, Joseph Myers wrote:
> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
> 
>> Or, if that is not possible, disable gcc-cvs mail for vendor and private
>> branches altogether?

I think this is desirable.  gcc-cvs should only mail about changes to 
master and release branches.

Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Jason Merrill wrote:

> On 1/15/20 9:56 AM, Joseph Myers wrote:
> > On Wed, 15 Jan 2020, Jakub Jelinek wrote:
> > 
> > > Or, if that is not possible, disable gcc-cvs mail for vendor and private
> > > branches altogether?
> 
> I think this is desirable.  gcc-cvs should only mail about changes to master
> and release branches.

I thinks commit mails for changes to all branches are desirable (including 
refs/heads/devel/ branches, including user and vendor branches) - but they 
should only be for changes that are new to the repository.  Existing 
practice in SVN was that all branches generated mails, we simply didn't 
have so many branches.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 11:30 AM, Joseph Myers wrote:
> On Wed, 15 Jan 2020, Jason Merrill wrote:
> 
>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>>
>>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private
>>>> branches altogether?
>>
>> I think this is desirable.  gcc-cvs should only mail about changes to master
>> and release branches.
> 
> I thinks commit mails for changes to all branches are desirable (including
> refs/heads/devel/ branches, including user and vendor branches) - but they
> should only be for changes that are new to the repository.  Existing
> practice in SVN was that all branches generated mails, we simply didn't
> have so many branches.

User branches in particular are likely to be very messy in the git 
world; in the old git mirror I would occasionally push a personal branch 
with work-in-progress patches that aren't nicely organized.  Perhaps one 
mail per push for those branches, rather than one per commit?

Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Iain Sandoe]

Joseph Myers <joseph@codesourcery.com> wrote:

> On Wed, 15 Jan 2020, Jason Merrill wrote:
> 
>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>> 
>>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private
>>>> branches altogether?
>> 
>> I think this is desirable.  gcc-cvs should only mail about changes to master
>> and release branches.
> 
> I thinks commit mails for changes to all branches are desirable (including 
> refs/heads/devel/ branches, including user and vendor branches) - but they 
> should only be for changes that are new to the repository.  Existing 
> practice in SVN was that all branches generated mails, we simply didn't 
> have so many branches.

For user/vendor branches that are rebased (a desirable action), is there any
mechanism for excluding unchanged rebased commits from being seen as
 “new”?

I’m guessing that public development branches will probably gravitate to the
no non-FF mode, if they are to be used by people other than the primary author

.. although that does somewhat limit things; rebasing WIP onto trunk and
reorganising / squashing is useful as well.

Iain

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Richard Earnshaw (lists)]

On 15/01/2020 16:30, Joseph Myers wrote:
> On Wed, 15 Jan 2020, Jason Merrill wrote:
> 
>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>>
>>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private
>>>> branches altogether?
>>
>> I think this is desirable.  gcc-cvs should only mail about changes to master
>> and release branches.
> 
> I thinks commit mails for changes to all branches are desirable (including
> refs/heads/devel/ branches, including user and vendor branches) - but they
> should only be for changes that are new to the repository.  Existing
> practice in SVN was that all branches generated mails, we simply didn't
> have so many branches.
> 

How about separate email list(s) for the vendor and personal spaces?  I 
do think changes there should be visible, but perhaps fewer folk will be 
interested in tracking them at the same level.

R.

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/15/20 11:37 AM, Iain Sandoe wrote:
> Joseph Myers <joseph@codesourcery.com> wrote:
> 
>> On Wed, 15 Jan 2020, Jason Merrill wrote:
>>
>>> On 1/15/20 9:56 AM, Joseph Myers wrote:
>>>> On Wed, 15 Jan 2020, Jakub Jelinek wrote:
>>>>
>>>>> Or, if that is not possible, disable gcc-cvs mail for vendor and private
>>>>> branches altogether?
>>>
>>> I think this is desirable.  gcc-cvs should only mail about changes to master
>>> and release branches.
>>
>> I thinks commit mails for changes to all branches are desirable (including
>> refs/heads/devel/ branches, including user and vendor branches) - but they
>> should only be for changes that are new to the repository.  Existing
>> practice in SVN was that all branches generated mails, we simply didn't
>> have so many branches.
> 
> For user/vendor branches that are rebased (a desirable action), is there any
> mechanism for excluding unchanged rebased commits from being seen as
>   “new”?
> 
> I’m guessing that public development branches will probably gravitate to the
> no non-FF mode, if they are to be used by people other than the primary author

Except that long-lived public development branches will need to merge 
master periodically, and that will be a non-FF merge.

Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Wed, 15 Jan 2020, Richard Earnshaw (lists) wrote:

> How about separate email list(s) for the vendor and personal spaces?  I do
> think changes there should be visible, but perhaps fewer folk will be
> interested in tracking them at the same level.

That's currently documented as a feature not supported by the hooks (the 
script to determine the lists to use only receives information about the 
files changed, not about the refs being updated).

I've now filed issues at https://github.com/AdaCore/git-hooks/issues for 
what I think are all the feature requests we have so far for making the 
hooks more configurable so particular features of use to GCC can be 
implemented without needing to patch the hooks themselves as at present.  
If you have a feature request of the form "the hooks should allow 
configuring X" it probably makes sense to file it there to help Joel track 
it.  However, policy questions about how we should configure the hooks for 
GCC (whether or not they depend on new hook features) would best be 
discussed here.

I'll add a check to the GCC hooks for commit messages whose first line is 
a single word, to prevent pushing commits whose summary is just 
"gcc/ChangeLog:" or similar.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> 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

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:
> > 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.

Couldn't it be then per-branch setting, whether to mail even commits
that aren't new to the repository or not (like I understood it is already
possible to decide per-branch whether to send mails at all)?
E.g. for GCC, I'd certainly like to see mails for all commits on the
trunk and release branches (but we don't allow merge commits on them
anyway), and for other branches (personal, vendor, devel) I think mailing
only about new commits not already in the repository would be better over
not mailing at all.

	Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Richard Earnshaw (lists)]

On 16/01/2020 14:11, Jakub Jelinek wrote:
> On Thu, Jan 16, 2020 at 12:40:02PM +0100, Joel Brobecker wrote:
>>> 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.
> 
> Couldn't it be then per-branch setting, whether to mail even commits
> that aren't new to the repository or not (like I understood it is already
> possible to decide per-branch whether to send mails at all)?
> E.g. for GCC, I'd certainly like to see mails for all commits on the
> trunk and release branches (but we don't allow merge commits on them
> anyway), and for other branches (personal, vendor, devel) I think mailing
> only about new commits not already in the repository would be better over
> not mailing at all.
> 
> 	Jakub
> 

The alternative I suggested to Joseph yesterday was a separate mailing 
list for all the personal and vendor commits.  But I think that would 
need a change to the hooks infrastructure.

R.

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jakub Jelinek]

On Thu, Jan 16, 2020 at 02:15:21PM +0000, Richard Earnshaw (lists) wrote:
> The alternative I suggested to Joseph yesterday was a separate mailing list
> for all the personal and vendor commits.  But I think that would need a
> change to the hooks infrastructure.

Would that solve it?  We have around 7500 to 8000 trunk commits a year
lately, so on the trunk+release branch mailing list it would be say 12000
mails a year, but if there are say 30 long lived devel/personal/vendor
branches that track trunk that would already mean 240000 mails alone in
those merge commits.  Sure, for branches tracking release branches it will
be less than that.  As a random sample, I've picked a random gcc trunk test
added in June and it got merged into 5 tracking branches later on 6 branches
tracking release branches.  That was with svn (but that one sent one mail
per merge, not hundreds), but git encourages that people push their devel
branches upstream.

	Jakub

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Thu, 16 Jan 2020, Joel Brobecker wrote:

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

The approach used by post-receive-email is to send a summary email but 
without resending the already-sent commits.  That seems appropriate to me.

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

A summary email just listing the commits merged seems much better than 
sending email maybe dozens of times for every commit to master.

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

I think it's desirable for development that *happens on* the personal and 
vendor branches to be visible in gcc-cvs - that is different from things 
getting merged into them.

Likewise for the refs/heads/devel/* development branches - 
non-fast-forward pushes are not permitted there, but such branches can 
expect to have lots of merges from master, and it's the actual development 
taking place *on* the branches - the new commits - that is of interest to 
see on gcc-cvs, not the merging of existing commits.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Thu, 16 Jan 2020, Jakub Jelinek wrote:

> Couldn't it be then per-branch setting, whether to mail even commits
> that aren't new to the repository or not (like I understood it is already
> possible to decide per-branch whether to send mails at all)?

Feel free to add such suggestions to the issues at 
<https://github.com/AdaCore/git-hooks/issues> (this one is 
<https://github.com/AdaCore/git-hooks/issues/9>).  Those issues are meant 
to track all the cases where we think some changes to the hooks would be 
useful for GCC (whether or not we've currently addressed them with local 
changes to the hooks).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> I think it's desirable for development that *happens on* the personal and 
> vendor branches to be visible in gcc-cvs - that is different from things 
> getting merged into them.
> 
> Likewise for the refs/heads/devel/* development branches - 
> non-fast-forward pushes are not permitted there, but such branches can 
> expect to have lots of merges from master, and it's the actual development 
> taking place *on* the branches - the new commits - that is of interest to 
> see on gcc-cvs, not the merging of existing commits.

Would it be sufficient to say that some branches would only
trigger a summary email, but not individual commit emails?
The downside is that you would not be getting the "diff" for
commits that are really completely new. But on the other hand,
it would fit better with the fact that user branches could have
frequent re-basing, thus causing the same commit email being sent
over and over at each rebase operation. It would also answer
the issue of the number of emails being sent when people are doing
a merge which brings in more commits than the max-emails number.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Iain Sandoe]

Joel Brobecker <brobecker@adacore.com> wrote:

>> I think it's desirable for development that *happens on* the personal and
>> vendor branches to be visible in gcc-cvs - that is different from things
>> getting merged into them.
>>
>> Likewise for the refs/heads/devel/* development branches -
>> non-fast-forward pushes are not permitted there, but such branches can
>> expect to have lots of merges from master, and it's the actual development
>> taking place *on* the branches - the new commits - that is of interest to
>> see on gcc-cvs, not the merging of existing commits.
>
> Would it be sufficient to say that some branches would only
> trigger a summary email, but not individual commit emails?
> The downside is that you would not be getting the "diff" for
> commits that are really completely new. But on the other hand,
> it would fit better with the fact that user branches could have
> frequent re-basing, thus causing the same commit email being sent
> over and over at each rebase operation. It would also answer
> the issue of the number of emails being sent when people are doing
> a merge which brings in more commits than the max-emails number.

AFAIU, we have access to more fine-grained information; isn’t it possible
to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
(because a ‘new’ commit does not have the extra fields set up for merges
  and rebases).

For example, I’d like to know that user/fred has rebased the branch i’m
interested in but OTOH, would not find the per-commit mails useful (so a
summary there is good).

If a push contains a combination of things - new work, merged and rebased
commits - then there would have to be some way to react to split or aggregate
the messages / diffs per commit id.

Iain

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Fri, 17 Jan 2020, Joel Brobecker wrote:

> Would it be sufficient to say that some branches would only
> trigger a summary email, but not individual commit emails?

Maybe that will end up being appropriate for users / vendors branches, if 
we can't effectively distinguish rebased commits from new ones.  But for 
shared fast-forward-only development branches, I think the individual 
commit emails are appropriate for commits new to the branch, while a 
summary email is appropriate for merges to the branch.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> AFAIU, we have access to more fine-grained information; isn’t it possible
> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> (because a ‘new’ commit does not have the extra fields set up for merges
>  and rebases).

In my opinion, this would create a lot of complication for the benefits
being gained. I also think that the more variations of behaviors you
introduce, the harder is becomes for people to know what's right and
what's not expected.  People then start getting surprised and start
asking about it. At best, it's just a quick answer, but in some cases,
it takes time to remember why we set things up the way they are and why
it doesn't make sense to change it. Over the years, I have really learnt
to enjoy the benefits of consistency, even if it is means some areas
are suboptimal. The "suboptimality" can still be a better compromise
overall than a superengineered system.

> For example, I’d like to know that user/fred has rebased the branch i’m
> interested in but OTOH, would not find the per-commit mails useful (so a
> summary there is good).
> 
> If a push contains a combination of things - new work, merged and rebased
> commits - then there would have to be some way to react to split or aggregate
> the messages / diffs per commit id.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/17/20 11:55 AM, Joel Brobecker wrote:
>> AFAIU, we have access to more fine-grained information; isn’t it possible
>> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
>> (because a ‘new’ commit does not have the extra fields set up for merges
>>   and rebases).
> 
> In my opinion, this would create a lot of complication for the benefits
> being gained. I also think that the more variations of behaviors you
> introduce, the harder is becomes for people to know what's right and
> what's not expected.  People then start getting surprised and start
> asking about it. At best, it's just a quick answer, but in some cases,
> it takes time to remember why we set things up the way they are and why
> it doesn't make sense to change it. Over the years, I have really learnt
> to enjoy the benefits of consistency, even if it is means some areas
> are suboptimal. The "suboptimality" can still be a better compromise
> overall than a superengineered system.

Spamming the list with emails every time someone merges master to their 
development branch sounds highly suboptimal, and likely to lead to 
disabling email entirely for those branches.  Is it so complicated to 
send a single email for a merge commit or non-fast-forward push?

Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> > Would it be sufficient to say that some branches would only
> > trigger a summary email, but not individual commit emails?
> 
> Maybe that will end up being appropriate for users / vendors branches, if 
> we can't effectively distinguish rebased commits from new ones.  But for 
> shared fast-forward-only development branches, I think the individual 
> commit emails are appropriate for commits new to the branch, while a 
> summary email is appropriate for merges to the branch.

OK. I will see if there is a reasonable way to provide this.

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joel Brobecker]

> > > AFAIU, we have access to more fine-grained information; isn’t it possible
> > > to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
> > > (because a ‘new’ commit does not have the extra fields set up for merges
> > >   and rebases).
> > 
> > In my opinion, this would create a lot of complication for the benefits
> > being gained. I also think that the more variations of behaviors you
> > introduce, the harder is becomes for people to know what's right and
> > what's not expected.  People then start getting surprised and start
> > asking about it. At best, it's just a quick answer, but in some cases,
> > it takes time to remember why we set things up the way they are and why
> > it doesn't make sense to change it. Over the years, I have really learnt
> > to enjoy the benefits of consistency, even if it is means some areas
> > are suboptimal. The "suboptimality" can still be a better compromise
> > overall than a superengineered system.
> 
> Spamming the list with emails every time someone merges master to their
> development branch sounds highly suboptimal, and likely to lead to disabling
> email entirely for those branches.  Is it so complicated to send a single
> email for a merge commit or non-fast-forward push?

Well, no. I was going so say that this is what I have been proposing
all along, except the way you phrased your suggestion above makes
me think that perhaps you want something more automatic, where the hooks
decide dynamically, rather than the choice being made by configuration.
So it's not exactly the same, but quite similar in spirit.  I think
we can find ways that will satisfy the need for fewer emails without
having to have that extra logic, though.

Also, you guys have to understand that you are all coming to me from
multiple directions at the same time, and making requests that are
not always easy to reconcile. I do completely understand that getting
hundreds of emails because of a merge into a development branch is far
from optimal, and it's absolutely not what I am suggesting we do here.
In fact, you'll see that I told Joseph in a separate mail that I will
think this over and try to come up with something that answers the
situation he described. What I am alerting people to is trying to
have special-case handling for every scenario we can conceive.

I'm wondering if we wouldn't be better off having this discussion live
over a meeting or a series of meetings...

-- 
Joel

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Iain Sandoe]

Joel Brobecker <brobecker@adacore.com> wrote:

>>>> AFAIU, we have access to more fine-grained information; isn’t it  
>>>> possible
>>>> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
>>>> (because a ‘new’ commit does not have the extra fields set up for merges
>>>>  and rebases).
>>>
>>> In my opinion, this would create a lot of complication for the benefits
>>> being gained. I also think that the more variations of behaviors you
>>> introduce, the harder is becomes for people to know what's right and
>>> what's not expected.  People then start getting surprised and start
>>> asking about it. At best, it's just a quick answer, but in some cases,
>>> it takes time to remember why we set things up the way they are and why
>>> it doesn't make sense to change it. Over the years, I have really learnt
>>> to enjoy the benefits of consistency, even if it is means some areas
>>> are suboptimal. The "suboptimality" can still be a better compromise
>>> overall than a superengineered system.
>>
>> Spamming the list with emails every time someone merges master to their
>> development branch sounds highly suboptimal, and likely to lead to  
>> disabling
>> email entirely for those branches.  Is it so complicated to send a single
>> email for a merge commit or non-fast-forward push?
>
> Well, no. I was going so say that this is what I have been proposing
> all along, except the way you phrased your suggestion above makes
> me think that perhaps you want something more automatic, where the hooks
> decide dynamically, rather than the choice being made by configuration.
> So it's not exactly the same, but quite similar in spirit.  I think
> we can find ways that will satisfy the need for fewer emails without
> having to have that extra logic, though.
>
> Also, you guys have to understand that you are all coming to me from
> multiple directions at the same time, and making requests that are
> not always easy to reconcile. I do completely understand that getting
> hundreds of emails because of a merge into a development branch is far
> from optimal, and it's absolutely not what I am suggesting we do here.
> In fact, you'll see that I told Joseph in a separate mail that I will
> think this over and try to come up with something that answers the
> situation he described. What I am alerting people to is trying to
> have special-case handling for every scenario we can conceive.

for my part, I was not trying to specify “requirements” - but identify  
different
scenarios that we might want to handle (better to decide how we want to do
things at the start, than to create changes later).

As a general rule, I’m 100% in favour of KISS.

> I'm wondering if we wouldn't be better off having this discussion live
> over a meeting or a series of meetings…

could be,

Iain

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Jason Merrill]

On 1/17/20 12:59 PM, Iain Sandoe wrote:
> Joel Brobecker <brobecker@adacore.com> wrote:
> 
>>>>> AFAIU, we have access to more fine-grained information; isn’t it possible
>>>>> to differentiate “new” commits, from ‘merges’ and from ‘rebases’?
>>>>> (because a ‘new’ commit does not have the extra fields set up for merges
>>>>>  and rebases).
>>>>
>>>> In my opinion, this would create a lot of complication for the benefits
>>>> being gained. I also think that the more variations of behaviors you
>>>> introduce, the harder is becomes for people to know what's right and
>>>> what's not expected.  People then start getting surprised and start
>>>> asking about it. At best, it's just a quick answer, but in some cases,
>>>> it takes time to remember why we set things up the way they are and why
>>>> it doesn't make sense to change it. Over the years, I have really 
>>>> learnt
>>>> to enjoy the benefits of consistency, even if it is means some areas
>>>> are suboptimal. The "suboptimality" can still be a better compromise
>>>> overall than a superengineered system.
>>>
>>> Spamming the list with emails every time someone merges master to their
>>> development branch sounds highly suboptimal, and likely to lead to disabling
>>> email entirely for those branches.  Is it so complicated to send a single
>>> email for a merge commit or non-fast-forward push?
>>
>> Well, no. I was going so say that this is what I have been proposing
>> all along, except the way you phrased your suggestion above makes
>> me think that perhaps you want something more automatic, where the hooks
>> decide dynamically, rather than the choice being made by configuration.
>> So it's not exactly the same, but quite similar in spirit.  I think
>> we can find ways that will satisfy the need for fewer emails without
>> having to have that extra logic, though.
>>
>> Also, you guys have to understand that you are all coming to me from
>> multiple directions at the same time, and making requests that are
>> not always easy to reconcile. I do completely understand that getting
>> hundreds of emails because of a merge into a development branch is far
>> from optimal, and it's absolutely not what I am suggesting we do here.
>> In fact, you'll see that I told Joseph in a separate mail that I will
>> think this over and try to come up with something that answers the
>> situation he described. What I am alerting people to is trying to
>> have special-case handling for every scenario we can conceive.
> 
> for my part, I was not trying to specify “requirements” - but identify different
> scenarios that we might want to handle (better to decide how we want to do
> things at the start, than to create changes later).

Indeed, this is largely a discussion about what is desirable and 
feasible.  How straightforward a particular request will be is helpful 
feedback.  Thank you, and sorry I got snarky above.

Jason

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Joseph Myers]

On Fri, 17 Jan 2020, Joel Brobecker wrote:

> Also, you guys have to understand that you are all coming to me from
> multiple directions at the same time, and making requests that are
> not always easy to reconcile. I do completely understand that getting

The issues filed on GitHub are meant to help track individual issues (both 
those we've fixed locally with GCC-specific patches and those, such as 
this one, that we haven't), although that doesn't guarantee there's a 
single consistent view of how best to address a particular issue.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Segher Boessenkool]

On Wed, Jan 15, 2020 at 04:37:49PM +0000, Iain Sandoe wrote:
> I’m guessing that public development branches will probably gravitate to the
> no non-FF mode, if they are to be used by people other than the primary author
> 
> .. although that does somewhat limit things; rebasing WIP onto trunk and
> reorganising / squashing is useful as well.

If a branch does rebase all people who commit to it need to make sure
not to overwrite others' work.  Your pushes are always non-fast-forward,
so you do not notice you did not incorporate someone else's new work if
you do not take care.

One easy way to avoid this is to just have only one person pushing to a
certain branch.


Segher

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Julien "_FrnchFrgg_" Rivaud]

Le 18/01/2020 à 18:49, Segher Boessenkool a écrit :
> On Wed, Jan 15, 2020 at 04:37:49PM +0000, Iain Sandoe wrote:
>> I’m guessing that public development branches will probably gravitate to the
>> no non-FF mode, if they are to be used by people other than the primary author
>>
>> .. although that does somewhat limit things; rebasing WIP onto trunk and
>> reorganising / squashing is useful as well.
> 
> If a branch does rebase all people who commit to it need to make sure
> not to overwrite others' work.  Your pushes are always non-fast-forward,
> so you do not notice you did not incorporate someone else's new work if
> you do not take care.

There is the git push --force-with-lease option to avoid that. Its goal 
is to force a non-fast-forward push, but only if the remote position 
(HEAD) is actually where you expect it to, that is no work you don't 
know about has been pushed in the mean time.

I strongly recommend to use --force-with-lease on non-user branches. 
User branches you usually control totally and are the only one to push 
to, so that's less an issue.

> 
> One easy way to avoid this is to just have only one person pushing to a
> certain branch.
> 
> 
> Segher
> 

Re: gcc-cvs mails for personal/vendor branches for merge commits

[Segher Boessenkool]

[ Please do reply to me when you reply to my mails.  Maybe gmane did that?
  Yet Another reason not to use gmane. ]

On Sat, Jan 18, 2020 at 11:04:12PM +0100, Julien _FrnchFrgg_ Rivaud wrote:
> Le 18/01/2020 à 18:49, Segher Boessenkool a écrit :
> >If a branch does rebase all people who commit to it need to make sure
> >not to overwrite others' work.  Your pushes are always non-fast-forward,
> >so you do not notice you did not incorporate someone else's new work if
> >you do not take care.
> 
> There is the git push --force-with-lease option to avoid that. Its goal 
> is to force a non-fast-forward push, but only if the remote position 
> (HEAD) is actually where you expect it to, that is no work you don't 
> know about has been pushed in the mean time.
> 
> I strongly recommend to use --force-with-lease on non-user branches. 
> User branches you usually control totally and are the only one to push 
> to, so that's less an issue.

Sure, that option helps to avoid problems when you do the wrong thing.
But you still need a plan what to do when there *are* problems, or to
avoid such problems in the first place.  You need some policy for when
the branch is rebased, and who does that, and how the other users are
supposed to learn about this.

(Using merges avoids this, it always makes a mess, instead it postpones
all the "make it a clean patch series" work to later.)


Segher