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