[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gcc
Subject:    Re: Proposal for the transition timetable for the move to GIT
From:       Jeff Law <law () redhat ! com>
Date:       2019-10-25 16:32:20
Message-ID: 5fc4a638-0b6e-fcbe-7920-85c6eecb0a44 () redhat ! com
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]