[[after-approval]]
=== After Review Approval
-The Git project has four integration branches: `pu`, `next`, `master`, and
-`maint`. Your change will be placed into `pu` fairly early on by the maintainer
+The Git project has four integration branches: `seen`, `next`, `master`, and
+`maint`. Your change will be placed into `seen` fairly early on by the maintainer
while it is still in the review process; from there, when it is ready for wider
testing, it will be merged into `next`. Plenty of early testers use `next` and
may report issues. Eventually, changes in `next` will make it to `master`,
base your work on the tip of the topic.
* A new feature should be based on `master` in general. If the new
- feature depends on a topic that is in `pu`, but not in `master`,
+ feature depends on a topic that is in `seen`, but not in `master`,
base your work on the tip of that topic.
* Corrections and enhancements to a topic not yet in `master` should
into the series.
* In the exceptional case that a new feature depends on several topics
- not in `master`, start working on `next` or `pu` privately and send
+ not in `master`, start working on `next` or `seen` privately and send
out patches for discussion. Before the final merge, you may have to
wait until some of the dependent topics graduate to `master`, and
rebase your work.
these parts should be based on their trees.
To find the tip of a topic branch, run `git log --first-parent
-master..pu` and look for the merge commit. The second parent of this
+master..seen` and look for the merge commit. The second parent of this
commit is the tip of the topic branch.
[[separate-commits]]
and cooked further and eventually graduates to `master`.
In any time between the (2)-(3) cycle, the maintainer may pick it up
-from the list and queue it to `pu`, in order to make it easier for
+from the list and queue it to `seen`, in order to make it easier for
people play with it without having to pick up and apply the patch to
their trees themselves.
master. `git pull --rebase` will automatically skip already-applied
patches, and will let you know. This works only if you rebase on top
of the branch in which your patch has been merged (i.e. it will not
- tell you if your patch is merged in pu if you rebase on top of
+ tell you if your patch is merged in `seen` if you rebase on top of
master).
* Read the Git mailing list, the maintainer regularly posts messages
* Using refspecs explicitly:
+
------------------------------------------------
-$ git fetch origin +pu:pu maint:tmp
+$ git fetch origin +seen:seen maint:tmp
------------------------------------------------
+
-This updates (or creates, as necessary) branches `pu` and `tmp` in
+This updates (or creates, as necessary) branches `seen` and `tmp` in
the local repository by fetching from the branches (respectively)
-`pu` and `maint` from the remote repository.
+`seen` and `maint` from the remote repository.
+
-The `pu` branch will be updated even if it does not fast-forward,
+The `seen` branch will be updated even if it does not fast-forward,
because it is prefixed with a plus sign; `tmp` will not be.
* Peek at a remote's branch, without configuring the remote in your local
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
-$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
+$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
-c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu
+c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
$ git remote add korg http://www.kernel.org/pub/scm/git/git.git
$ git ls-remote --tags korg v\*
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
$ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git switch topic/one && git rebase master <6>
-$ git switch -C pu next <7>
+$ git switch -C seen next <7>
$ git merge topic/one topic/two && git merge hold/linus <8>
$ git switch maint
$ git cherry-pick master~4 <9>
$ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
-$ git fetch ko && for branch in master maint next pu <11>
+$ git fetch ko && for branch in master maint next seen <11>
do
git show-branch ko/$branch $branch <12>
done
<1> see what you were in the middle of doing, if anything.
<2> see which branches haven't been merged into `master` yet.
Likewise for any other integration branches e.g. `maint`, `next`
-and `pu` (potential updates).
+and `seen`.
<3> read mails, save ones that are applicable, and save others
that are not quite ready (other mail readers are available).
<4> apply them, interactively, with your sign-offs.
<5> create topic branch as needed and apply, again with 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.
+<7> restart `seen` every time from the next.
<8> and bundle topic branches still cooking.
<9> backport a critical fix.
<10> create a signed tag.
fetch = refs/heads/*:refs/remotes/ko/*
push = refs/heads/master
push = refs/heads/next
- push = +refs/heads/pu
+ push = +refs/heads/seen
push = refs/heads/maint
------------
There is a fourth official branch that is used slightly differently:
-* 'pu' (proposed updates) is an integration branch for things that are
- not quite ready for inclusion yet (see "Integration Branches"
- below).
+* 'seen' (patches seen by the maintainer) is an integration branch for
+ things that are not quite ready for inclusion yet (see "Integration
+ Branches" below).
Each of the four branches is usually a direct descendant of the one
above it.
Conceptually, the feature enters at an unstable branch (usually 'next'
-or 'pu'), and "graduates" to 'master' for the next release once it is
+or 'seen'), and "graduates" to 'master' for the next release once it is
considered stable enough.
right after the testing, you can even publish this branch, for example
to give the testers a chance to work with it, or other developers a
chance to see if their in-progress work will be compatible. `git.git`
-has such an official throw-away integration branch called 'pu'.
+has such an official throw-away integration branch called 'seen'.
Branch management for a release
described in the previous section.
-Branch management for next and pu after a feature release
+Branch management for next and seen after a feature release
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After a feature release, the integration branch 'next' may optionally be
If you do this, then you should make a public announcement indicating
that 'next' was rewound and rebuilt.
-The same rewind and rebuild process may be followed for 'pu'. A public
-announcement is not necessary since 'pu' is a throw-away branch, as
+The same rewind and rebuild process may be followed for 'seen'. A public
+announcement is not necessary since 'seen' is a throw-away branch, as
described above.
origin/man
origin/master
origin/next
- origin/pu
+ origin/seen
origin/todo
------------------------------------------------
projects / thirdparty / git.git / commitdiff
