This is the mail archive of the gcc@gcc.gnu.org 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 <segher@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


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