Joel Brobecker <brobec...@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
