diff options
| author | Johannes Schindelin <johannes.schindelin@gmx.de> | 2020-06-25 12:18:57 +0000 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2020-06-25 09:18:53 -0700 |
| commit | 828197de8f2c1103e23a37d0ee32b76e899cf267 (patch) | |
| tree | 277422a155520b5e09cc41a5a317e366d277b76b /Documentation/gitworkflows.txt | |
| parent | af6b65d45ef179ed52087e80cb089f6b2349f4ec (diff) | |
| download | git-828197de8f2c1103e23a37d0ee32b76e899cf267.tar.gz | |
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>
Diffstat (limited to 'Documentation/gitworkflows.txt')
| -rw-r--r-- | Documentation/gitworkflows.txt | 16 |
1 files changed, 8 insertions, 8 deletions
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt index abc0dc6bc7..2db7ba7842 100644 --- a/Documentation/gitworkflows.txt +++ b/Documentation/gitworkflows.txt @@ -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: -* '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. @@ -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 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 @@ -291,7 +291,7 @@ This will not happen if the content of the branches was verified as 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 @@ -319,8 +319,8 @@ so. 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. |