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: Proposal for the transition timetable for the move to GIT

On Sat, Dec 28, 2019 at 05:11:47PM +0000, Richard Earnshaw (lists) wrote:
> On 28/12/2019 12:19, Segher Boessenkool wrote:
> > Branch merges do not mesh well with our commit policies, fwiw:
> > everything should normally be posted for public review on the mailing
> > lists.  This does not really work for commits that have been set in
> > stone months before.
> I disagree.  The review comments will show up as additional commits on
> the branch and can be tracked back to such events.  Once history gets
> flattened into a major single commit it's significantly more effort to
> drill down into the history and find out why if we've lost the merge
> information.

Oh, I'm not talking about historical merges.  I'm saying we shouldn't do
future merges, where we can help that.  It disagrees with our documented
"submitting patches" protocol.

Nothing should ever be flattened to a single commit.  But before patches
hit trunk, the patch series can be made nicer than it was at the start
of its development.

All merges lose information.  All of them.  You take two branches, and
cut and paste between the two, but you never show which part is from
what, or how conflicts were resolved, etc.  All this can be reconstructed
of course -- you know the inputs, and you have the output -- but the info
isn't there directly, and there is no why or what.  If you're lucky there
is a mail about it, or the merge commit itself goes into it a bit.


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