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

Le 29/12/2019 à 12:02, Richard Biener a écrit :
On December 29, 2019 11:41:00 AM GMT+01:00, Segher Boessenkool <> wrote:
On Sun, Dec 29, 2019 at 02:40:45AM +0100, Julien FrnchFrgg Rivaud
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
"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

Linux has most development done in separate trees, one for each
That is not how GCC works.

I was talking about , see heading
"submitting patches" :-)

Nothing should ever be flattened to a single commit.  But before
hit trunk, the patch series can be made nicer than it was at the
of its development.
I quite agree with that, and it resonates with my TL;DR chunk of text

Yup.  Rebasing is superior to merging in many ways.  Merging is
if there is parallel development of (mostly) independent things.
aren't that, usually: they can be rebased easily, and they should be
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.


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