From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 99491 invoked by alias); 19 Sep 2019 15:49: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 99483 invoked by uid 89); 19 Sep 2019 15:49:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-Received:ac8, time, H*c:alternative, emails X-HELO: mail-qt1-f172.google.com Received: from mail-qt1-f172.google.com (HELO mail-qt1-f172.google.com) (209.85.160.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 15:48:59 +0000 Received: by mail-qt1-f172.google.com with SMTP id u22so4760998qtq.13 for ; Thu, 19 Sep 2019 08:48:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceryinstitute.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CoEQM4sTNoJT+IcqxeOn2QocM2htTAmORIFU5Rxstdk=; b=WRyglZczubn1bNAmEYdCLNC9r/OKGJ4DQSoRCnRwj3bPgnm2yU7Bum+7LglusfHHR4 +wwo0xWjsLlgLVN49eMQr2Z613Rx5/Fj08o7S4pvH/F93lUxgsDcIP0ywj81Yb2mkVun 7QpoinH1jW18qMIrmzNGcm3e8PUC01JgijiJbI/jrUrXzFmUADN3qqROyW4mcnOFpZ6z sqUHjxMhYjZJRvVqqGKBj08Kp6mR09MMqgqEjWs4OvuwHeGF+s2uTAEiqgFdCBS1HBWz HzgVN2l3L45EAgWJTcCb6LB41G+EPIDyJRF14SJkEH26mmEr2fgra0nuCjXBLHWAMacG tKYQ== MIME-Version: 1.0 References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> <1fd7e15b-beb0-d85b-e36f-dc88948e3942@arm.com> In-Reply-To: <1fd7e15b-beb0-d85b-e36f-dc88948e3942@arm.com> From: Damian Rouson Date: Thu, 19 Sep 2019 15:49:00 -0000 Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT To: "Richard Earnshaw (lists)" Cc: Janne Blomqvist , gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00148.txt.bz2 Thanks to you and Janne for the thoughtful replies. I understand better the immediate goals now. Damian On Thu, Sep 19, 2019 at 08:31 Richard Earnshaw (lists) < Richard.Earnshaw@arm.com> wrote: > On 19/09/2019 13:04, Janne Blomqvist wrote: > > On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists) > > wrote: > >> There should be NO CHANGE to the other processes and policies that we > >> have, eg patch reviews, ChangeLog policies etc at this time. Adding > >> requirements for this will just slow down the transition by > >> over-complicating things. > > > > A little aside; I fully support the above, lets change one thing at a > > time. But it would be nice with some short documentation about the git > > workflow that we'll start with (which, presumably, at least initially > > shouldn't differ too much from the svn workflow many are familiar with > > for the reasons you mention above), particularly for those not that > > familiar with git, or have only used git together with github or such. > > > > One thing that's unclear to me is how should I actually make my stuff > > appear in the public repo? Say I want to work on some particular > > thing: > > > > 1. git checkout -b pr1234-foo # A private branch based on latest trunk > > 2. Then when I'm happy, I send out a patch for review, either manually > > or with git format-patch + send-email. > > 3. Patch goes through a few revisions, and is approved. > > 4. Now what? > > 4a) Do I merge my private branch to master (err, trunk?), then commit > and push? > > 4b) Or do I first rebase my branch on top of the latest master, to > > produce a slightly less branchy history? > > 4c) Or do I (manually?) apply my patch on master, to create a linear > history? > > 4d) Something else entirely? > > > > Thanks, > > > > I believe the current intent is that, at least for now, the trunk and > release branches will be simple linear chains of commits (no merges). > > This is the same workflow as is currently used in gdb, binutils and > glibc, and we will likely lift the hooks to enforce this from those > projects. See the separate discussion on the git hooks for a bit more > detail. > > What individuals do on private branches is up to them. Similarly for > development branches (policy set by branch owner), but they will need > linearizing (or maybe squashing) before they can be merged to trunk. > > The aim is to keep the workflow as close as possible to the existing one > to start with. I'd expect most developers to work by posting patches to > gcc-patches as before, though 'git format-patch' emails may well be > acceptable (quite a few developers use a workflow much like that already). > > This will all be written up before the switch... > > R. >