This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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:
https://public-inbox.org/git/cover.1577185374.git.liu.denton@gmail.com/T/#m4f20ec1d987a7d3b10a0f4fa0ebb7c64acf75320
(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.
_FrnchFrgg_