Everyday contents (was Re: What's cooking in git.git (Jul 2014, #04; Tue, 22))

[Junio C Hamano <gitster@pobox.com>]

Continued: this message only covers the third part (out of the four sections).

| Integrator[[Integrator]]
| ------------------------
| 
| 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[1] 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.

| Examples
| ~~~~~~~~
| 
| 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)
these days.

| +
| ------------
| $ 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
    do
        git show-branch ko/$branch $branch
    done

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
| sign-offs.
| <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:

	(in .git/config)
	[remote "ko"]
        	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
still valid.

| <12> push out the bleeding edge.

s/edge./edge, together with new tags that point into my history./

| <13> push the tag out, too.

Drop this.