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

["Richard Earnshaw (lists)" <Richard.Earnshaw@arm.com>]

On 19/09/2019 15:42, Damian Rouson wrote:
> On Thu, Sep 19, 2019 at 5:04 AM Janne Blomqvist <blomqvist.janne@gmail.com>
> wrote:
> 
>>
>> 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:
>>
> 
> This is essentially a git workflow question.  A simple and useful workflow
> to consider is the
> GitHub Flow: https://guides.github.com/introduction/flow/.  Others to
> consider are on the
> GitLab Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html and
> on Atlassian's
> Git Flow page: https://docs.gitlab.com/ee/workflow/gitlab_flow.html.  Where
> will the GCC
> git repository be hosted?
> 
> 
>> 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.
>>
> 
> Will GCC allow workflows other than emailing patches?  It could make
> contributing more
> inviting to new developers.   A large community of developers has grown up
> around the
> above workflows and are used to using the related tools.  I realize
> emailing patches
> probably seems simple to GCC developers, but that practice is one of the
> main reasons I
> haven't contributed code to GCC even though I have supported GCC
> development financially
> and I frequently interact with GCC developers. My problems with email have
> been many.
> I have often forgotten to set my emails to plain text so my emails to GCC
> lists bounce and
> I have to resend them (often hours later if I didn't see the bounce right
> away).  When I
> receive patches from GCC developers, I get frustrated with determining what
> -p argument
> to pass when applying the patch. I'm equally daunted with the process of
> searching through
> emails to find related discussions rather than having all the dialogue
> about a pull request
> (which contains the same information as a patch) in one place.  And with
> plain-text emails
> as the medium, I really miss the ability to format dialogues with Markdown,
> including inserting
> hyperlinks but also to tie comments to specific lines of code in a browser
> interface to the
> pull request, etc.
> 
> 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?
>>
> 
> It's safer to first merge master into your branch and then retest with all
> the new commits
> that have hit master since you branched.  If you test right after merging
> and find no
> problems (and no new commits hit master while you're testing), then the
> head of your
> branch will reflect the state master will reach when you merge into master
> so you know
> it's safe to do so.
> 
> 
>> 4b) Or do I first rebase my branch on top of the latest master, to
>> produce a slightly less branchy history?
>>
> 
> A lot of people find rebasing to be overly complicated and error-prone
> (with the exception
> of interactive rebasing for the purpose of squashing commits that haven't
> been pushed to
> the remote repository).  The above merging steps are easier at the expense
> of having
> merge commits in the history, which I think is good to better document the
> branching
> history.
> 
> 
>> 4c) Or do I (manually?) apply my patch on master, to create a linear
>> history?
> 
> 
> See above.  I recommend "git merge" over manually applying patches.
> 
> 
>> 4d) Something else entirely?
>>
> 
> A lot of the testing can be automated.  For example, on GitHub, git hooks
> can be set up
> to ensure that if a branch has an open pull request against master (or
> other designated
> branches), tests run for that branch every time a new commit is pushed to
> it.
> 
> Damian
> 

There will be NO changes to the basic workflow at the time of the 
transition, other than those that are strictly required by using git 
instead of SVN (ie you now have to type "git clone" rather than "svn 
checkout" and, for committers, "git push" rather than "svn checkin").

This is not to suggest that at some later date the workflows cannot 
change, but at this point in time the only change will be the underlying 
storage mechanism for the master repository.  As Segher said, NO SCOPE 
CREEP.

R.