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

[Damian Rouson <damian@sourceryinstitute.org>]

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