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

[Janne Blomqvist <blomqvist.janne@gmail.com>]

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,
-- 
Janne Blomqvist