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

[Jason Merrill <jason at redhat dot com>]

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