From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 80431 invoked by alias); 29 Dec 2019 12:15:48 -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 80328 invoked by uid 89); 29 Dec 2019 12:15:37 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=automated, hole 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 12:15:35 +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 xBTCFU4S017922; Sun, 29 Dec 2019 06:15:30 -0600 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id xBTCFTNo017921; Sun, 29 Dec 2019 06:15:29 -0600 Date: Sun, 29 Dec 2019 12:15:00 -0000 From: Segher Boessenkool To: Richard Biener Cc: gcc@gcc.gnu.org, Julien FrnchFrgg Rivaud Subject: Re: Proposal for the transition timetable for the move to GIT Message-ID: <20191229121529.GB3191@gate.crashing.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0DAF74B5-1F78-4871-B720-993341A9030D@gmail.com> User-Agent: Mutt/1.4.2.3i X-IsSubscribed: yes X-SW-Source: 2019-12/txt/msg00497.txt.bz2 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