On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud wrote: > >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. > > I don't see how that can be correct. Linux is heavily "submitting > patches" based, with stringent reviews on LKML, yet heavily uses merges.
Linux has most development done in separate trees, one for each maintainer. That is not how GCC works. I was talking about https://gcc.gnu.org/contribute.html , see heading "submitting patches" :-) > >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. > > I quite agree with that, and it resonates with my TL;DR chunk of text above. Yup. Rebasing is superior to merging in many ways. Merging is appropriate if there is parallel development of (mostly) independent things. Features aren't that, usually: they can be rebased easily, and they should be posted for review anyway. It is very easy to use merges more often than is useful, and it hurts. Segher
