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