Le 29/12/2019 à 12:02, Richard Biener a écrit :
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?
Not exactly. It will if the bug was not introduced by the merge, but if
so then "git bisect" will start looking at individual commits in the
branch, which is IMHO very good. It is far easier to have a bug pinned
to a single change (or say 5-6 commits, if all were not buildable or
testable), than a whole branch. At worst, no commit is testable in the
branch except the last, and git will say that the bug was introduced in
the branch, which is not worse that what you'd get without a merge commit.
Julien
