From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74169 invoked by alias); 29 Dec 2019 16:32:14 -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 74159 invoked by uid 89); 29 Dec 2019 16:32:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=our X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.110.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 29 Dec 2019 16:32:12 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CBD2831B; Sun, 29 Dec 2019 08:32:10 -0800 (PST) Received: from [192.168.1.2] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 13AAD3F703; Sun, 29 Dec 2019 08:32:09 -0800 (PST) Subject: Re: Proposal for the transition timetable for the move to GIT To: Segher Boessenkool , Richard Biener Cc: gcc@gcc.gnu.org, Julien FrnchFrgg Rivaud References: <20191226183553.GK10088@tucnak> <20191228121921.GW4505@gate.crashing.org> <20191228202824.GZ4505@gate.crashing.org> <20191229104100.GA3191@gate.crashing.org> <0DAF74B5-1F78-4871-B720-993341A9030D@gmail.com> <20191229121529.GB3191@gate.crashing.org> From: Richard Earnshaw Message-ID: <22325b4b-ea35-5434-490e-47ea31a051e3@foss.arm.com> Date: Sun, 29 Dec 2019 16:32: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: <20191229121529.GB3191@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00509.txt.bz2 On 29/12/2019 12:15, Segher Boessenkool wrote: > On Sun, Dec 29, 2019 at 12:02:51PM +0100, Richard Biener wrote: >> 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 visible but not when bisecting (by default). It would also make the series relatedness obvious and avoids splitting it with a commit race (if that is possible with git). > > "git bisect" actually goes all the way down the rabbit hole, it tries to > find the first bad commit in the range you marked as starting as "good", > ending as "bad". > > It is pretty confusing to do if there are many merges, especially if many > commits end up not building at all. But you can always "git bisect skip" > stuff (it just eats time, and it hampers automated bisecting). > > The really nasty cases are when the code does build, but fails for > unrelated reasons. > > We require every commit to be individually tested, and if we *do* allow > merges, that should still be done imo. Which again makes merging less > useful: if you are going to rebase your branch anyway (to fix simple > stuff), why not rebase it onto trunk! > >> IMHO exact workflow for merging a patch series as opposed to a single patch should be documented. > > Yes. It isn't actually documented in so many words for what we do now, > either, but it would be good to have. > > > Segher > We agreed that for changes in our current workflow practices we'd defer that until *after* we'd switched to git; so this is getting off topic. On the other hand, we do need to sort out what we do with existing merge history, as that forms part of the conversion. Can we stick to what's relevant, please, at least in this thread? R.