From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80800 invoked by alias); 29 Dec 2019 11:02:59 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 80789 invoked by uid 89); 29 Dec 2019 11:02:58 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=exact, our X-HELO: mail-wm1-f65.google.com Received: from mail-wm1-f65.google.com (HELO mail-wm1-f65.google.com) (209.85.128.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 11:02:57 +0000 Received: by mail-wm1-f65.google.com with SMTP id f129so12081310wmf.2 for ; Sun, 29 Dec 2019 03:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=kvrVwVDAFKleVEoZJ2uXdNdxlwralw85A6eb1ydka6Y=; b=r5Qu8o98I73S98YqWg1NW2AWHGfbMLkaVFsAkek3kpiArW6sdai3mISK9L77brPqka XuKcNg7K7DmS1XKuZZyLdzu+r0AHN6XLvhQLLwQHXh67kl3kWnUyResnOKC8rgaCkej5 a0lIrCY9ysx4+mm32TAFyBRWAfjAiImhgyObt8nrmo4V6SjYPf2Ca5xD0sg352Fq48bF Z8Ii5yYDGQfGHnCryB10z2/zYQu1Zn/LZL50FCzJaAFXZneTl+saStxMrm3+atHm8rhg SlBiUn6QOat2g8DoRDrm0zKgl4arKjmiBxPUJGMVJv6Gq1bQK2qrgUpVHsNrPcqehCqs 2W1Q== Return-Path: Received: from [192.168.178.32] (x5f73618e.dyn.telefonica.de. [95.115.97.142]) by smtp.gmail.com with ESMTPSA id x18sm41541648wrr.75.2019.12.29.03.02.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 29 Dec 2019 03:02:54 -0800 (PST) Date: Sun, 29 Dec 2019 11:02:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <20191229104100.GA3191@gate.crashing.org> References: <5DCEA32B-3E36-4400-B931-9F4E2A8F3FA5@linaro.org> <20191226183553.GK10088@tucnak> <20191228121921.GW4505@gate.crashing.org> <20191228202824.GZ4505@gate.crashing.org> <20191229104100.GA3191@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: Proposal for the transition timetable for the move to GIT To: gcc@gcc.gnu.org,Segher Boessenkool ,Julien FrnchFrgg Rivaud From: Richard Biener Message-ID: <0DAF74B5-1F78-4871-B720-993341A9030D@gmail.com> X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00494.txt.bz2 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 >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. >>=20 >> I don't see how that can be correct. Linux is heavily "submitting=20 >> patches" based, with stringent reviews on LKML, yet heavily uses >merges.=20 > >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. >>=20 >> 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.=20 >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 visibl= e but not when bisecting (by default). It would also make the series relate= dness obvious and avoids splitting it with a commit race (if that is possib= le with git).=20 IMHO exact workflow for merging a patch series as opposed to a single patch= should be documented.=20 Richard.=20 > >Segher