Autogenerated HTML docs for v2.27.0-343-g4a0fcf

1 files changed, 9 insertions, 9 deletions

diff --git a/gitworkflows.html b/gitworkflows.html
index 2953da672..0fe7fe47b 100644
--- a/gitworkflows.html
+++ b/gitworkflows.html
@@ -832,16 +832,16 @@ management.  The following subsections discuss the important points.</p></div>
 <div class="ulist"><ul>

 <li>

 <p>

-<em>pu</em> (proposed updates) is an integration branch for things that are

-  not quite ready for inclusion yet (see "Integration Branches"

-  below).

+<em>seen</em> (patches seen by the maintainer) is an integration branch for

+  things that are not quite ready for inclusion yet (see "Integration

+  Branches" below).

 </p>

 </li>

 </ul></div>

 <div class="paragraph"><p>Each of the four branches is usually a direct descendant of the one

 above it.</p></div>

 <div class="paragraph"><p>Conceptually, the feature enters at an unstable branch (usually <em>next</em>

-or <em>pu</em>), and "graduates" to <em>master</em> for the next release once it is

+or <em>seen</em>), and "graduates" to <em>master</em> for the next release once it is

 considered stable enough.</p></div>

 </div>

 <div class="sect2">

@@ -946,7 +946,7 @@ throw-away branch.  You must never base any work on such a branch!</p></div>
 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.  <code>git.git</code>

-has such an official throw-away integration branch called <em>pu</em>.</p></div>

+has such an official throw-away integration branch called <em>seen</em>.</p></div>

 </div>

 <div class="sect2">

 <h3 id="_branch_management_for_a_release">Branch management for a release</h3>

@@ -1021,7 +1021,7 @@ This will not happen if the content of the branches was verified as
 described in the previous section.</p></div>

 </div>

 <div class="sect2">

-<h3 id="_branch_management_for_next_and_pu_after_a_feature_release">Branch management for next and pu after a feature release</h3>

+<h3 id="_branch_management_for_next_and_seen_after_a_feature_release">Branch management for next and seen after a feature release</h3>

 <div class="paragraph"><p>After a feature release, the integration branch <em>next</em> may optionally be

 rewound and rebuilt from the tip of <em>master</em> using the surviving

 topics on <em>next</em>:</p></div>

@@ -1061,8 +1061,8 @@ slate to retry, and a feature release is a good point in history to do
 so.</p></div>

 <div class="paragraph"><p>If you do this, then you should make a public announcement indicating

 that <em>next</em> was rewound and rebuilt.</p></div>

-<div class="paragraph"><p>The same rewind and rebuild process may be followed for <em>pu</em>. A public

-announcement is not necessary since <em>pu</em> is a throw-away branch, as

+<div class="paragraph"><p>The same rewind and rebuild process may be followed for <em>seen</em>. A public

+announcement is not necessary since <em>seen</em> is a throw-away branch, as

 described above.</p></div>

 </div>

 </div>

@@ -1225,7 +1225,7 @@ other options.</p></div>
 <div id="footer">

 <div id="footer-text">

 Last updated

- 2020-03-10 08:03:13 PDT

+ 2020-07-06 22:33:22 PDT

 </div>

 </div>

 </body>