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

2020-01-20 Thread 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

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

2020-01-18 Thread Julien "_FrnchFrgg_" Rivaud
Le 18/01/2020 à 18:49, Segher Boessenkool a écrit : On Wed, Jan 15, 2020 at 04:37:49PM +, 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

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

2020-01-18 Thread Segher Boessenkool
On Wed, Jan 15, 2020 at 04:37:49PM +, 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

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

2020-01-17 Thread 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

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

2020-01-17 Thread Jason Merrill
On 1/17/20 12:59 PM, Iain Sandoe wrote: 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).

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

2020-01-17 Thread Iain Sandoe
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

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

2020-01-17 Thread 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

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

2020-01-17 Thread 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

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

2020-01-17 Thread 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

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

2020-01-17 Thread 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

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

2020-01-17 Thread 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

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

2020-01-17 Thread Iain Sandoe
Joel Brobecker 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

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

2020-01-17 Thread 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,

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

2020-01-16 Thread 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

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

2020-01-16 Thread 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.

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

2020-01-16 Thread Jakub Jelinek
On Thu, Jan 16, 2020 at 02:15:21PM +, 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

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

2020-01-16 Thread 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 and

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

2020-01-16 Thread 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 > > and the long > > series of

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

2020-01-16 Thread 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

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

2020-01-15 Thread 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

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

2020-01-15 Thread Jason Merrill
On 1/15/20 11:37 AM, Iain Sandoe wrote: 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

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

2020-01-15 Thread 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.

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

2020-01-15 Thread Iain Sandoe
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

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

2020-01-15 Thread 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.

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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

2020-01-15 Thread Joseph Myers
On Wed, 15 Jan 2020, Jakub Jelinek wrote: > On Wed, Jan 15, 2020 at 02:56:45PM +, 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 > > >

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

2020-01-15 Thread Jakub Jelinek
On Wed, Jan 15, 2020 at 02:56:45PM +, 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 >

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

2020-01-15 Thread 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

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

2020-01-15 Thread 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