kernel
/
git
mirror of https://git.kernel.org/pub/scm/git/git.git
1
0
Fork 0
Code Releases Activity
Browse Source

docs: adjust for the recent rename of `pu` to `seen` 

As of "What's cooking in git.git (Jun 2020, #04; Mon, 22)", there is no
longer any `pu` branch, but a `seen` branch.

While we technically do not even need to update the manual pages, it
makes sense to update them because they clearly talk about branches in
git.git.

Please note that in two instances, this patch not only updates the
branch name, but also the description "(proposed updates)".

Where appropriate, quotes have been added for readability.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
maint
Johannes Schindelin 5 years ago committed by Junio C Hamano
parent
af6b65d45e
commit
828197de8f
7 changed files with 27 additions and 27 deletions
Whitespace
Show all changes Ignore whitespace when comparing lines Ignore changes in amount of whitespace Ignore changes in whitespace at EOL
Unified View
Diff Options
Show Stats Download Patch File Download Diff File
  1. 4
      Documentation/MyFirstContribution.txt
  2. 10
      Documentation/SubmittingPatches
  3. 8
      Documentation/git-fetch.txt
  4. 4
      Documentation/git-ls-remote.txt
  5. 10
      Documentation/giteveryday.txt
  6. 16
      Documentation/gitworkflows.txt
  7. 2
      Documentation/user-manual.txt

4
Documentation/MyFirstContribution.txt
Unescape View File

@ -1179,8 +1179,8 @@ look at the section below this one for some context.)
[[after-approval]] [[after-approval]]
=== After Review Approval === After Review Approval


The Git project has four integration branches: `pu`, `next`, `master`, and The Git project has four integration branches: `seen`, `next`, `master`, and
`maint`. Your change will be placed into `pu` fairly early on by the maintainer `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 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 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`, may report issues. Eventually, changes in `next` will make it to `master`,

10
Documentation/SubmittingPatches
Unescape View File

@ -18,7 +18,7 @@ change is relevant to.
base your work on the tip of the topic. base your work on the tip of the topic.


* A new feature should be based on `master` in general. If the new * 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. base your work on the tip of that topic.


* Corrections and enhancements to a topic not yet in `master` should * Corrections and enhancements to a topic not yet in `master` should
@ -27,7 +27,7 @@ change is relevant to.
into the series. into the series.


* In the exceptional case that a new feature depends on several topics * 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 out patches for discussion. Before the final merge, you may have to
wait until some of the dependent topics graduate to `master`, and wait until some of the dependent topics graduate to `master`, and
rebase your work. rebase your work.
@ -37,7 +37,7 @@ change is relevant to.
these parts should be based on their trees. these parts should be based on their trees.


To find the tip of a topic branch, run `git log --first-parent 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. commit is the tip of the topic branch.


[[separate-commits]] [[separate-commits]]
@ -423,7 +423,7 @@ help you find out who they are.
and cooked further and eventually graduates to `master`. and cooked further and eventually graduates to `master`.


In any time between the (2)-(3) cycle, the maintainer may pick it up 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 people play with it without having to pick up and apply the patch to
their trees themselves. their trees themselves.


@ -434,7 +434,7 @@ their trees themselves.
master. `git pull --rebase` will automatically skip already-applied master. `git pull --rebase` will automatically skip already-applied
patches, and will let you know. This works only if you rebase on top 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 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). master).


* Read the Git mailing list, the maintainer regularly posts messages * Read the Git mailing list, the maintainer regularly posts messages

8
Documentation/git-fetch.txt
Unescape View File

@ -255,14 +255,14 @@ refspec.
* Using refspecs explicitly: * 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) 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. 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 * Peek at a remote's branch, without configuring the remote in your local

4
Documentation/git-ls-remote.txt
Unescape View File

@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3 7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2 c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub 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 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 remote add korg http://www.kernel.org/pub/scm/git/git.git
$ git ls-remote --tags korg v\* $ git ls-remote --tags korg v\*
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99 d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99

10
Documentation/giteveryday.txt
Unescape View File

@ -278,13 +278,13 @@ $ git am -3 -i -s ./+to-apply <4>
$ compile/test $ compile/test
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5> $ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
$ git switch topic/one && git rebase master <6> $ 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 merge topic/one topic/two && git merge hold/linus <8>
$ git switch maint $ git switch maint
$ git cherry-pick master~4 <9> $ git cherry-pick master~4 <9>
$ compile/test $ compile/test
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10> $ 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 do
git show-branch ko/$branch $branch <12> git show-branch ko/$branch $branch <12>
done done
@ -294,14 +294,14 @@ $ git push --follow-tags ko <13>
<1> see what you were in the middle of doing, if anything. <1> see what you were in the middle of doing, if anything.
<2> see which branches haven't been merged into `master` yet. <2> see which branches haven't been merged into `master` yet.
Likewise for any other integration branches e.g. `maint`, `next` 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 <3> read mails, save ones that are applicable, and save others
that are not quite ready (other mail readers are available). that are not quite ready (other mail readers are available).
<4> apply them, interactively, with your sign-offs. <4> apply them, interactively, with your sign-offs.
<5> create topic branch as needed and apply, again with 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 <6> rebase internal topic branch that has not been merged to the
master or exposed as a part of a stable branch. 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. <8> and bundle topic branches still cooking.
<9> backport a critical fix. <9> backport a critical fix.
<10> create a signed tag. <10> create a signed tag.
@ -323,7 +323,7 @@ repository at kernel.org, and looks like this:
fetch = refs/heads/*:refs/remotes/ko/* fetch = refs/heads/*:refs/remotes/ko/*
push = refs/heads/master push = refs/heads/master
push = refs/heads/next push = refs/heads/next
push = +refs/heads/pu push = +refs/heads/seen
push = refs/heads/maint push = refs/heads/maint
------------ ------------



16
Documentation/gitworkflows.txt
Unescape View File

@ -85,15 +85,15 @@ As a given feature goes from experimental to stable, it also


There is a fourth official branch that is used slightly differently: There is a fourth official branch that is used slightly differently:


* 'pu' (proposed updates) is an integration branch for things that are * 'seen' (patches seen by the maintainer) is an integration branch for
not quite ready for inclusion yet (see "Integration Branches" things that are not quite ready for inclusion yet (see "Integration
below). Branches" below).


Each of the four branches is usually a direct descendant of the one Each of the four branches is usually a direct descendant of the one
above it. above it.


Conceptually, the feature enters at an unstable branch (usually 'next' 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. considered stable enough.




@ -207,7 +207,7 @@ If you make it (very) clear that this branch is going to be deleted
right after the testing, you can even publish this branch, for example 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 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` 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 Branch management for a release
@ -291,7 +291,7 @@ This will not happen if the content of the branches was verified as
described in the previous section. 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 After a feature release, the integration branch 'next' may optionally be
@ -319,8 +319,8 @@ so.
If you do this, then you should make a public announcement indicating If you do this, then you should make a public announcement indicating
that 'next' was rewound and rebuilt. that 'next' was rewound and rebuilt.


The same rewind and rebuild process may be followed for 'pu'. A public The same rewind and rebuild process may be followed for 'seen'. A public
announcement is not necessary since 'pu' is a throw-away branch, as announcement is not necessary since 'seen' is a throw-away branch, as
described above. described above.





2
Documentation/user-manual.txt
Unescape View File

@ -347,7 +347,7 @@ $ git branch -r
origin/man origin/man
origin/master origin/master
origin/next origin/next
origin/pu origin/seen
origin/todo origin/todo
------------------------------------------------ ------------------------------------------------



Write Preview
Loading…
Cancel
Save