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