This is the mail archive of the
mailing list for the GCC project.
Re: gcc-cvs mails for personal/vendor branches for merge commits
> > > 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...