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>
Johannes Schindelin committed
Jun 25, 2020 at 12:18 UTC
828197de8f2c1103e23a37d0ee32b76e899cf267
7 files changed
+27
-27
Documentation/MyFirstContribution.txt
+2
-2
@@ -1179,8 +1179,8 @@ look at the section below this one for some context.)
1179
[[after-approval]]
1180
=== After Review Approval
1181
1182
-The Git project has four integration branches: `pu`, `next`, `master`, and
1183
-`maint`. Your change will be placed into `pu` fairly early on by the maintainer
1182
+The Git project has four integration branches: `seen`, `next`, `master`, and
1183
+`maint`. Your change will be placed into `seen` fairly early on by the maintainer
1184
while it is still in the review process; from there, when it is ready for wider
1185
testing, it will be merged into `next`. Plenty of early testers use `next` and
1186
may report issues. Eventually, changes in `next` will make it to `master`,
Documentation/SubmittingPatches
+5
-5
@@ -18,7 +18,7 @@ change is relevant to.
18
base your work on the tip of the topic.
19
20
* A new feature should be based on `master` in general. If the new
21
- feature depends on a topic that is in `pu`, but not in `master`,
21
+ feature depends on a topic that is in `seen`, but not in `master`,
22
base your work on the tip of that topic.
23
24
* Corrections and enhancements to a topic not yet in `master` should
@@ -27,7 +27,7 @@ change is relevant to.
27
into the series.
28
29
* In the exceptional case that a new feature depends on several topics
30
- not in `master`, start working on `next` or `pu` privately and send
30
+ not in `master`, start working on `next` or `seen` privately and send
31
out patches for discussion. Before the final merge, you may have to
32
wait until some of the dependent topics graduate to `master`, and
33
rebase your work.
@@ -37,7 +37,7 @@ change is relevant to.
37
these parts should be based on their trees.
38
39
To find the tip of a topic branch, run `git log --first-parent
40
-master..pu` and look for the merge commit. The second parent of this
40
+master..seen` and look for the merge commit. The second parent of this
41
commit is the tip of the topic branch.
42
43
[[separate-commits]]
@@ -423,7 +423,7 @@ help you find out who they are.
423
and cooked further and eventually graduates to `master`.
424
425
In any time between the (2)-(3) cycle, the maintainer may pick it up
426
-from the list and queue it to `pu`, in order to make it easier for
426
+from the list and queue it to `seen`, in order to make it easier for
427
people play with it without having to pick up and apply the patch to
428
their trees themselves.
429
@@ -434,7 +434,7 @@ their trees themselves.
434
master. `git pull --rebase` will automatically skip already-applied
435
patches, and will let you know. This works only if you rebase on top
436
of the branch in which your patch has been merged (i.e. it will not
437
- tell you if your patch is merged in pu if you rebase on top of
437
+ tell you if your patch is merged in `seen` if you rebase on top of
438
master).
439
440
* Read the Git mailing list, the maintainer regularly posts messages
Documentation/git-fetch.txt
+4
-4
@@ -255,14 +255,14 @@ refspec.
255
* Using refspecs explicitly:
256
+
257
------------------------------------------------
258
-$ git fetch origin +pu:pu maint:tmp
258
+$ git fetch origin +seen:seen maint:tmp
259
------------------------------------------------
260
+
261
-This updates (or creates, as necessary) branches `pu` and `tmp` in
261
+This updates (or creates, as necessary) branches `seen` and `tmp` in
262
the local repository by fetching from the branches (respectively)
263
-`pu` and `maint` from the remote repository.
263
+`seen` and `maint` from the remote repository.
264
+
265
-The `pu` branch will be updated even if it does not fast-forward,
265
+The `seen` branch will be updated even if it does not fast-forward,
266
because it is prefixed with a plus sign; `tmp` will not be.
267
268
* Peek at a remote's branch, without configuring the remote in your local
Documentation/git-ls-remote.txt
+2
-2
@@ -101,9 +101,9 @@ f25a265a342aed6041ab0cc484224d9ca54b6f41 refs/tags/v0.99.1
101
7ceca275d047c90c0c7d5afb13ab97efdf51bd6e refs/tags/v0.99.3
102
c5db5456ae3b0873fc659c19fafdde22313cc441 refs/tags/v0.99.2
103
0918385dbd9656cab0d1d81ba7453d49bbc16250 refs/tags/junio-gpg-pub
104
-$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master pu rc
104
+$ git ls-remote http://www.kernel.org/pub/scm/git/git.git master seen rc
105
5fe978a5381f1fbad26a80e682ddd2a401966740 refs/heads/master
106
-c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/pu
106
+c781a84b5204fb294c9ccc79f8b3baceeb32c061 refs/heads/seen
107
$ git remote add korg http://www.kernel.org/pub/scm/git/git.git
108
$ git ls-remote --tags korg v\*
109
d6602ec5194c87b0fc87103ca4d67251c76f233a refs/tags/v0.99
Documentation/giteveryday.txt
+5
-5
@@ -278,13 +278,13 @@ $ git am -3 -i -s ./+to-apply <4>
278
$ compile/test
279
$ git switch -c hold/linus && git am -3 -i -s ./+hold-linus <5>
280
$ git switch topic/one && git rebase master <6>
281
-$ git switch -C pu next <7>
281
+$ git switch -C seen next <7>
282
$ git merge topic/one topic/two && git merge hold/linus <8>
283
$ git switch maint
284
$ git cherry-pick master~4 <9>
285
$ compile/test
286
$ git tag -s -m "GIT 0.99.9x" v0.99.9x <10>
287
-$ git fetch ko && for branch in master maint next pu <11>
287
+$ git fetch ko && for branch in master maint next seen <11>
288
do
289
git show-branch ko/$branch $branch <12>
290
done
@@ -294,14 +294,14 @@ $ git push --follow-tags ko <13>
294
<1> see what you were in the middle of doing, if anything.
295
<2> see which branches haven't been merged into `master` yet.
296
Likewise for any other integration branches e.g. `maint`, `next`
297
-and `pu` (potential updates).
297
+and `seen`.
298
<3> read mails, save ones that are applicable, and save others
299
that are not quite ready (other mail readers are available).
300
<4> apply them, interactively, with your sign-offs.
301
<5> create topic branch as needed and apply, again with sign-offs.
302
<6> rebase internal topic branch that has not been merged to the
303
master or exposed as a part of a stable branch.
304
-<7> restart `pu` every time from the next.
304
+<7> restart `seen` every time from the next.
305
<8> and bundle topic branches still cooking.
306
<9> backport a critical fix.
307
<10> create a signed tag.
@@ -323,7 +323,7 @@ repository at kernel.org, and looks like this:
323
fetch = refs/heads/*:refs/remotes/ko/*
324
push = refs/heads/master
325
push = refs/heads/next
326
- push = +refs/heads/pu
326
+ push = +refs/heads/seen
327
push = refs/heads/maint
328
------------
329
Documentation/gitworkflows.txt
+8
-8
@@ -85,15 +85,15 @@ As a given feature goes from experimental to stable, it also
85
86
There is a fourth official branch that is used slightly differently:
87
88
-* 'pu' (proposed updates) is an integration branch for things that are
89
- not quite ready for inclusion yet (see "Integration Branches"
90
- below).
88
+* 'seen' (patches seen by the maintainer) is an integration branch for
89
+ things that are not quite ready for inclusion yet (see "Integration
90
+ Branches" below).
91
92
Each of the four branches is usually a direct descendant of the one
93
above it.
94
95
Conceptually, the feature enters at an unstable branch (usually 'next'
96
-or 'pu'), and "graduates" to 'master' for the next release once it is
96
+or 'seen'), and "graduates" to 'master' for the next release once it is
97
considered stable enough.
98
99
@@ -207,7 +207,7 @@ If you make it (very) clear that this branch is going to be deleted
207
right after the testing, you can even publish this branch, for example
208
to give the testers a chance to work with it, or other developers a
209
chance to see if their in-progress work will be compatible. `git.git`
210
-has such an official throw-away integration branch called 'pu'.
210
+has such an official throw-away integration branch called 'seen'.
211
212
213
Branch management for a release
@@ -291,7 +291,7 @@ This will not happen if the content of the branches was verified as
291
described in the previous section.
292
293
294
-Branch management for next and pu after a feature release
294
+Branch management for next and seen after a feature release
295
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
296
297
After a feature release, the integration branch 'next' may optionally be
@@ -319,8 +319,8 @@ so.
319
If you do this, then you should make a public announcement indicating
320
that 'next' was rewound and rebuilt.
321
322
-The same rewind and rebuild process may be followed for 'pu'. A public
323
-announcement is not necessary since 'pu' is a throw-away branch, as
322
+The same rewind and rebuild process may be followed for 'seen'. A public
323
+announcement is not necessary since 'seen' is a throw-away branch, as
324
described above.
325
326
Documentation/user-manual.txt
+1
-1
@@ -347,7 +347,7 @@ $ git branch -r
347
origin/man
348
origin/master
349
origin/next
350
- origin/pu
350
+ origin/seen
351
origin/todo
352
------------------------------------------------
353