From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40164 invoked by alias); 29 Dec 2019 11:42:17 -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 40154 invoked by uid 89); 29 Dec 2019 11:42:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=H*F:D*fr, discrete, H*r:212.27.42, modifications X-HELO: smtp1-g21.free.fr Received: from smtp1-g21.free.fr (HELO smtp1-g21.free.fr) (212.27.42.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 11:42:15 +0000 Received: from [IPv6:2a01:cb14:b74:a500:c65:2afb:4db2:7170] (unknown [IPv6:2a01:cb14:b74:a500:c65:2afb:4db2:7170]) (Authenticated sender: frnchfrgg) by smtp1-g21.free.fr (Postfix) with ESMTPSA id 1565AB004B6; Sun, 29 Dec 2019 12:42:08 +0100 (CET) Subject: Re: Proposal for the transition timetable for the move to GIT To: Segher Boessenkool Cc: gcc@gcc.gnu.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> From: Julien '_FrnchFrgg_' RIVAUD Message-ID: <98729b61-2322-4244-7bde-f29c7e654d59@free.fr> Date: Sun, 29 Dec 2019 11:42:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20191229104100.GA3191@gate.crashing.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-12/txt/msg00495.txt.bz2 Le 29/12/2019 à 11:41, Segher Boessenkool a écrit : > 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 mentioned the git development for a reason. They use merges for *everything*, including patchsets by people who never contributed before and might never contribute afterwards. The very *concept* of a DVCS is that each developer has a separate tree, not each maintainer. I'm not arguing that you should go that route, it seems a bit extreme to me. But outright refusing merges on the basis they are painful is (if you can accept the strong word) ludicrous. > 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. That's not what I agreed with. I agreed with « the patch series can be made nicer », which I took to be the contrary of « append patches at the end ». Rebasing is *one* of the ways to do that, especially interactive rebasing to shuffle patches around, check that each step compiles and passes the full test suite (updating it if needed and correct), reword messages, and think a lot of times about the best progression. But I never opposed rebasing to merging. In particular, I clearly wrote that *even if you rebased*, there are very strong arguments out there about refusing fast-forward merges, that is *always* generate a real merge commit, with a cover letter message roughly corresponding to the mail people send on the ML to convince people their patch series are worth including in GCC. That leaves individual commit messages to explain the local rationale behind each discrete change (not the how, as it is readily apparent from the code, unless the code is very clever and then an in-code comment is warranted) > Merging is appropriate if there is parallel development of (mostly) independent things. Which is almost always the case. > Features aren't that, usually: they can be rebased easily, and they should be posted > for review anyway. How often successive features checked into GCC are dependent on each other ? The fact that they can be rebased either way and easily is almost a testimony of that. And the fact that they need review has nothing to do with anything. > It is very easy to use merges more often than is useful, and it hurts. And it is very easy to use SVN-like workflows, and it hurts far more. SVN, due to its centrality and inherent impossibility to encode logical relationships between changes (as opposed to time-based evolution), slowly impaired most developers mind openness about what can be done in a worthwhile VCS. Moving to git is an opportunity to at last free yourselves, not continue that narrow treading on SVN paths. SVN was like an almanac listing successive events without any analysis. That's not History (as in the field of study). Git at least can let you express and use to your common benefit logical links between modifications. Don't miss that train. Merges are not scary when the tools are good. Even the logs are totally usable with a lot of merges, with suitable tools. The tool has to adapt, not you. Julien