This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Help with new GCC git workflow...

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 master*):

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 <my-feature-branch>:refs/users/<yourname>/<thebranchpublicname>

(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 repository.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]