From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30774 invoked by alias); 19 Sep 2019 15:30:50 -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 30162 invoked by uid 89); 19 Sep 2019 15:30:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-5.6 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=individuals, H*M:beb0 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; Thu, 19 Sep 2019 15:30:42 +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 CF31428; Thu, 19 Sep 2019 08:30:40 -0700 (PDT) Received: from e120077-lin.cambridge.arm.com (e120077-lin.cambridge.arm.com [10.2.206.91]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id F30333F575; Thu, 19 Sep 2019 08:30:39 -0700 (PDT) Subject: Re: Proposal for the transition timetable for the move to GIT To: Janne Blomqvist Cc: gcc mailing list References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> From: "Richard Earnshaw (lists)" Message-ID: <1fd7e15b-beb0-d85b-e36f-dc88948e3942@arm.com> Date: Thu, 19 Sep 2019 15:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00146.txt.bz2 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.