From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3660 invoked by alias); 15 Jan 2020 09:50:01 -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 3646 invoked by uid 89); 15 Jan 2020 09:50:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:CAH6eHd, Youll, You'll X-HELO: mail-lj1-f195.google.com Received: from mail-lj1-f195.google.com (HELO mail-lj1-f195.google.com) (209.85.208.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 15 Jan 2020 09:49:51 +0000 Received: by mail-lj1-f195.google.com with SMTP id y6so17848788lji.0 for ; Wed, 15 Jan 2020 01:49:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Qf5SKCwWlgDPkGvzph2kJn+Mu8EkbX3TSMp+2hU5RCM=; b=Xh5r4vPSIBvcKo2/5F3w+SkKsVuhJ9VA/pO7ws0RTNkaBBtLYCuezZPiCuj3mcs0EH +C3Kdz7EvqQwdH37nWdxa/2lA1k0yAqIuUPWwy1rruyOkInETMXZl8BVl5CZU0w4Sxma khfAHko5PuOvL8vn8QmXkuz00i6SKDhTgeVsIT+1LBiwQKsZMhZJpVYHUD6yXdvK9xWQ atc1sTU3fadQSH9Il4SmZFk+3cJuX7w88/PhgB775BmuiNr2qdGMMODQ2xWZCzIvnKZO lng6aR+AytvXADhejr5TfmND2wmSqD3STYAmLlvgNyl4FunMyjfejrEl02MwmpHSCJP+ KdxA== MIME-Version: 1.0 References: <2f7edf26-6ea1-a607-2177-1a708b5691a6@linux.ibm.com> <20200114165136.GB34102@thyrsus.com> In-Reply-To: From: Richard Biener Date: Wed, 15 Jan 2020 10:36:00 -0000 Message-ID: Subject: Re: Help with new GCC git workflow... To: Jonathan Wakely Cc: "Eric S. Raymond" , Peter Bergner , GCC Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2020-01/txt/msg00289.txt.bz2 On Wed, Jan 15, 2020 at 10:33 AM Jonathan Wakely wrote: > > On Wed, 15 Jan 2020 at 08:40, Richard Biener wrote: > > > > On Tue, Jan 14, 2020 at 5:51 PM Eric S. Raymond wrote: > > > > > > Peter Bergner : > > > > At this point, I get a little confused. :-) I know to submit my patch > > > > for review, I'll want to squash my commits down into one patch, but how > > > > does one do that? Should I do that now or only when I'm ready to > > > > push this change to the upstream repo or ??? Do I need to even do that? > > > > > > If you want to squash a commit series, the magic is git rebase -i. You > > > give that a number of commits to look back at at and you'll get a buffer > > > instructing you how to squash and shuffle that series. You'll also be able > > > to edit the commit message. > > > > > > I like to write really fine-grained commits when I'm developing, then > > > squash before pushing so the public repo commits always go from "tests > > > pass" to "test pass". That way you can do clean bisections on the > > > public history. > > > > The question is wheter one could achieve this with branches? That is, > > have master contain a merge commit from a branch that contains the > > fine-grained commits? Because for forensics those can be sometimes > > useful. > > A "merge commit" is a special kind of commit that creates a commit > with two (or more) parents, and joins two separate trees. We don't > allow that in master or release branches. > > But you can definitely take a series of commits from a branch and put > that whole series into master, without squashing them into one commit. > You just have to rebase the patches onto master (or cherry-pick each > one of the series in turn, but rebase is easier for multiple patches). > That makes a series of new commits on master, each one corresponding > to one of he commits in the branch (but new commits with new hashes, > because the new commit has a different parent than the one on the > branch did). That's fine, but it's not a "merge commit". > > > > That basically would somehow record that a series of commits are "related" > > (the merge commit has two parents). Of course usually the merge commit > > is empty and thus non-existant but then for branch merges it still > > always exists? > > A merge commit might be empty, but it's not non-existent. But we don't > allow merge commits on master, and we don't need to allow them in > order to have a series of related commits go in together. OK, I see. Guess we should document to not think that a git push of a series represented as multiple commits are a "single" commit on master then and that if you do that individual commits need to be bootstrapped and tested. So, maybe prevent pushes of multiple commits for safety? As for not allowing merges I guess we could eventually relax this to allow merge commits that are "empty" and the referred refs have linear history from the merge parent? Richard.