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.earns...@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.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. >
