From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-201275-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 59236 invoked by alias); 29 Dec 2019 10:41:08 -0000
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
Received: (qmail 59227 invoked by uid 89); 29 Dec 2019 10:41:07 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_20,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=reviews, lkml, LKML, resonates
X-HELO: gate.crashing.org
Received: from gate.crashing.org (HELO gate.crashing.org) (63.228.1.57) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 10:41:04 +0000
Received: from gate.crashing.org (localhost.localdomain [127.0.0.1])	by gate.crashing.org (8.14.1/8.14.1) with ESMTP id xBTAf03w018628;	Sun, 29 Dec 2019 04:41:00 -0600
Received: (from segher@localhost)	by gate.crashing.org (8.14.1/8.14.1/Submit) id xBTAf0Zx018627;	Sun, 29 Dec 2019 04:41:00 -0600
Date: Sun, 29 Dec 2019 10:41:00 -0000
From: Segher Boessenkool <segher@kernel.crashing.org>
To: Julien FrnchFrgg Rivaud <frnchfrgg@free.fr>
Cc: gcc@gcc.gnu.org
Subject: Re: Proposal for the transition timetable for the move to GIT
Message-ID: <20191229104100.GA3191@gate.crashing.org>
References: <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <alpine.DEB.2.21.1912261632130.28986@digraph.polyomino.org.uk> <20191226183553.GK10088@tucnak> <alpine.DEB.2.21.1912261858420.30156@digraph.polyomino.org.uk> <d9a8603d-f59e-beeb-508a-807f78f9e126@arm.com> <alpine.DEB.2.21.1912271130410.7351@digraph.polyomino.org.uk> <20191228121921.GW4505@gate.crashing.org> <ba3f7672-5b6c-b4e2-0182-ac4cf2fb6393@arm.com> <20191228202824.GZ4505@gate.crashing.org> <qu906t$6tmm$1@blaine.gmane.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <qu906t$6tmm$1@blaine.gmane.org>
User-Agent: Mutt/1.4.2.3i
X-IsSubscribed: yes
X-SW-Source: 2019-12/txt/msg00493.txt.bz2

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