> > > 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... -- Joel
