Re: Proposal for the transition timetable for the move to GIT

[Damian Rouson <damian@sourceryinstitute.org>]

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)
> > <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
> 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.
>