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
