Continued: this message only covers the third part (out of the four sections).
| A fairly central person acting as the integrator in a group
| project receives changes made by others, reviews and integrates
| them and publishes the result for others to use, using these
| commands in addition to the ones needed by participants.
This definition of who an "integrator" is, and it being a separate
role when we discuss various workflows, are still sound, I think.
| * linkgit:git-pull to merge from your trusted lieutenants.
Among these enumerated items, we may want to reword this a little
bit to hint that this section also applies to GitHub pull-request
workflow. However, I am not sure how their "merge without first
locally checking" action on their website fits in the picture.
| My typical Git day.::
This probably shouldn't talk about "My" in the first place, but in
any case I work somewhat differently (cf. howto/maintain-git.txt)
| $ git status <1>
| $ git show-branch <2>
This is more like "git branch --no-merged master" (and similarly for
'next' and 'pu'), and is helped by "Meta/cook -w" but this document
is a wrong place to talk about the latter.
| $ mailx <3>
| & s 2 3 4 5 ./+to-apply
| & s 7 8 ./+hold-linus
| & q
| $ git checkout -b topic/one master
| $ git am -3 -i -s -u ./+to-apply <4>
No need to give -u these days.
| $ compile/test
| $ git checkout -b hold/linus && git am -3 -i -s -u ./+hold-linus <5>
Again, no "-u" necessary.
| $ git checkout topic/one && git rebase master <6>
| $ git checkout pu && git reset --hard next <7>
| $ git merge topic/one topic/two && git merge hold/linus <8>
| $ git checkout maint
| $ git cherry-pick master~4 <9>
| $ compile/test
| $ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
| $ git fetch ko && git show-branch master maint 'tags/ko-*' <11>
This step I still use show-branch, but like this:
for branch in master maint next pu
git show-branch ko/$branch $branch
and the purpose explained in the footnote is still valid.
| $ git push ko <12>
| $ git push ko v0.99.9x <13>
I no longer have to do the last step <13>, instead the step <12>
reads more like
git push --follow-tags ko
| <1> see what I was in the middle of doing, if any.
| <2> see what topic branches I have and think about how ready
| they are.
With "show-branch" replaced with "branch --no-merged", the purpose
of this step is still the same.
| <3> read mails, save ones that are applicable, and save others
| that are not quite ready.
| <4> apply them, interactively, with my sign-offs.
| <5> create topic branch as needed and apply, again with my
| <6> rebase internal topic branch that has not been merged to the
| master or exposed as a part of a stable branch.
| <7> restart `pu` every time from the next.
| <8> and bundle topic branches still cooking.
| <9> backport a critical fix.
| <10> create a signed tag.
| <11> make sure I did not accidentally rewind master beyond what I
| already pushed out. `ko` shorthand points at the repository I have
| at kernel.org, and looks like this:
No longer it looks like that ;-)
| $ cat .git/remotes/ko
| URL: kernel.org:/pub/scm/git/git.git
| Pull: master:refs/tags/ko-master
| Pull: next:refs/tags/ko-next
| Pull: maint:refs/tags/ko-maint
| Push: master
| Push: next
| Push: +pu
| Push: maint
... because we encourage people to use in-config description of
remotes these days, which should look like this:
url = kernel.org:/pub/scm/git/git.git
fetch = refs/heads/*:refs/remotes/ko/*
push = refs/heads/master
push = refs/heads/next
push = +refs/heads/pu
push = refs/heads/maint
Also tracking is done via refs/remotes/ko/, no longer with tags/.
| In the output from `git show-branch`, `master` should have
| everything `ko-master` has, and `next` should have
| everything `ko-next` has.
With s|ko-master|ko/master| and s|ko-next|ko/next|, the above is
| <12> push out the bleeding edge.
s/edge./edge, together with new tags that point into my history./
| <13> push the tag out, too.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html