This is the mail archive of the
mailing list for the GCC project.
Re: Proposal for the transition timetable for the move to GIT
- From: Damian Rouson <damian at sourceryinstitute dot org>
- To: "Richard Earnshaw (lists)" <Richard dot Earnshaw at arm dot com>
- Cc: Janne Blomqvist <blomqvist dot janne at gmail dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Thu, 19 Sep 2019 08:48:46 -0700
- Subject: Re: Proposal for the transition timetable for the move to GIT
- References: <firstname.lastname@example.org> <CAO9iq9EekoYVUp+VaRe8xzSDdmkKg9VjDOJgka8ptr=53LjOCg@mail.gmail.com> <email@example.com>
Thanks to you and Janne for the thoughtful replies. I understand better
the immediate goals now.
On Thu, Sep 19, 2019 at 08:31 Richard Earnshaw (lists) <
> On 19/09/2019 13:04, Janne Blomqvist wrote:
> > On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists)
> > <Richard.Earnshaw@arm.com> 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
> > 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
> 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...