From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 34837 invoked by alias); 19 Sep 2019 12:04: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 34828 invoked by uid 89); 19 Sep 2019 12:04:50 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=Proposal, Something, HX-Languages-Length:1525, aside X-HELO: mail-yb1-f172.google.com Received: from mail-yb1-f172.google.com (HELO mail-yb1-f172.google.com) (209.85.219.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2019 12:04:49 +0000 Received: by mail-yb1-f172.google.com with SMTP id t15so1220854ybg.7 for ; Thu, 19 Sep 2019 05:04:48 -0700 (PDT) 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=wvwa5COnUJ1pkFf3O5yZFviBAWvQj7MPX+t6E58z9Ms=; b=gguxfn23e3Jt2G+OusT8o2VF30G2/O7UXSvho1ZITSh1U6J+T0/0PNoUP1yHGnwPjo 57zDP/nXL6G4EXdhNB/UdK2hrGsKMtJwNIJ6Zy9GV4GTX/v6+ryy+Zx+80Vfm00Ssiib 9mzaseB9DD2mKLgSiaO4UvLtoFQLsVc4eumpb206VQ9S4urVk6X4U0eqh3AmArgvf4+i pGT2nLChkQsYH6U+hu6zw713cXb9SMNO5jqr8YLP0FPGS/ea3nWEvKx2EPIMHK4Ukoos Ys9r30UFGWzj3OmvCBzkEwrGdNgXe2MRnLVlF0TFEiSoVlWn8y/Z+qlTHAIdnmPAYQZ3 bm0g== MIME-Version: 1.0 References: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> In-Reply-To: <1685e719-738f-dd4e-c39c-c08e495b202e@arm.com> From: Janne Blomqvist Date: Thu, 19 Sep 2019 12:04:00 -0000 Message-ID: Subject: Re: Proposal for the transition timetable for the move to GIT To: "Richard Earnshaw (lists)" Cc: gcc mailing list Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00142.txt.bz2 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, -- Janne Blomqvist