On 19/09/2019 13:04, Janne Blomqvist wrote:
On Tue, Sep 17, 2019 at 3:02 PM Richard Earnshaw (lists)
<richard.earns...@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.
