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

[Jeff Law <law at redhat dot com>]

On 10/25/19 8:10 AM, Richard Earnshaw (lists) wrote:
> 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.
Agreed.  Let's deal with the conversion and only the conversion.  Any
discussion about changing the workflows should be deferred until after
the conversion is done.

jeff