On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool <seg...@kernel.crashing.org> wrote: >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.
For bisecting trunk a merge would be a single commit, right? So I could see value in preserving a patch series where individual steps might introduce temporary issues as a branch merge (after rebasing) so the series is visible but not when bisecting (by default). It would also make the series relatedness obvious and avoids splitting it with a commit race (if that is possible with git). IMHO exact workflow for merging a patch series as opposed to a single patch should be documented. Richard. > >Segher
