> 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. > For example, I’d like to know that user/fred has rebased the branch i’m > interested in but OTOH, would not find the per-commit mails useful (so a > summary there is good). > > If a push contains a combination of things - new work, merged and rebased > commits - then there would have to be some way to react to split or aggregate > the messages / diffs per commit id. -- Joel
