Help with new GCC git workflow...

Julien "FrnchFrgg" Rivaud
Tue Jan 14 18:06:00 GMT 2020

Le 14/01/2020 à 17:07, Peter Bergner a écrit :
> As somewhat of a git newbie and given gcc developers will do a git push of
> our changes rather than employing a git pull development model, I'd like
> a little hand holding on what my new gcc git workflow should be, so I don't
> screw up the upstream repo by pushing something to the wrong place. :-)
> I know enough that I should be using local branches to develop my changes,
> so I want something like:
>    git checkout master
>    git pull
>    git checkout -b <branchNameHere>
>    <modify and add new files>
>    git commit -m "My commit message1"
>    <modify and add new files>
>    git commit -m "My commit message2"
>    <modify and add new files>
>    git commit -m "My commit message3"
>    <all done!>
> At this point, I get a little confused. :-)  I know to submit my patch
> for review, I'll want to squash my commits down into one patch, but how
> does one do that?

Whether you really want to squash your commits into one patch really 
depends on their nature. If all of the commits are really part of the 
same unit of meaning and you just committed regularly as a "timely 
backup" procedure, then yes you want to squash. In that case

git rebase -i master

is your friend: it will open an editor with the list of all your commits 
and commands applied to them (by default, "pick", that is replay the 
diff without change apart from conflict automatic resolution when 
possible and manual intervention if not). You can reorder the commits, 
and/or squash some of them together.

If the commits are actually steps to attaining a goal where each step is 
valid on its own, then you can IMHO submit the set of patches to the ML. 
An example of a set with 17 patches on the git ML is:

(Note that the first mail, labeled PATCH 00/17, will probably end up 
being the commit message of the merge commit, because git prefers real 
merges, even if rebased, to fast-forward merges. For GCC that wouldn't 
be so with the current policy AFAIU)

If you think that the change is big enough to warrant such patch series, 
and the commits you made as you went are not that, then again

git rebase -i master

is your friend, using more "edit" steps, or even branch again from 
master and use git "cherry-pick" and manual rewriting to build up a new 
set, comparing regularly with the end result of <branchNameHere>. A lot 
of work for sure, but worth it in the end.

> Also, when I'm ready to push this "change" upstream to trunk, I'll need
> to move this over to my master and then push.

You don't need to move anything over to your master. You can use "git 
format-patch" and/or "git send-email" to have git convert your branch to 
a series of mails to send for review to the ML (most submissions to the 
git ML are done that way).

When the patch set is rewiewed and Acked-By the module 
owners/maintainers, either they push themselves (using "git am" to 
convert the mails to a local branch, then push), or if you have the 
rights you do it yourself.

To do so, you need to first

git checkout master
git pull
git checkout <my-feature-branch>
git rebase master

If the rebase was not completely trivial, I guess you should submit your 
changed patches again to the ML (this is subject to appreciation by the 
gcc community of course).

If the rebase was successful, you can then push (which will *update 

git push origin <my-feature-branch>:master

If you just want to push to your user namespace, then you don't 
necessarily need to rebase (though I recommend doing so regularly), and 
you should do

git push origin 

(check if I got the namespacing right of course)

There are "git config" settings for pushing that can help you 
automatically push any branch to a branch with the same name in the 
refs/users/<yourname>/ namespace when you say

git push

without any argument, but I'm not going to explain those here. I hope 
they will be soon in the documentation about how to set up your git 

> ...and this is just for changes going to trunk.  How does all this change
> when I want to push changes to a release or vendor branch?

For a vendor branch, you'd

git push origin <mylocalbranch>:refs/vendors/<vendorname>/<branchname>

Again, defining a remote other than origin, that already map to the 
correct namespace, would be better. In git you can have as many 
"upstream" repositories as you want, and even several of them can be the 
exact same one with slightly different push or fetch configuration.


More information about the Gcc mailing list