This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]