docs: verify/bisect: add and fetch stable branches ahead of time

Add and fetch all required stable branches ahead of time. This fixes a
bug, as readers that wanted to bisect a regression within a stable or
longterm series otherwise did not have them available at the right time.
This way also matches the flow somewhat better and avoids some "if you
haven't already added it" phrases that otherwise become necessary in
future changes.

Signed-off-by: Thorsten Leemhuis <linux@leemhuis.info>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Link: https://lore.kernel.org/r/57dcf312959476abe6151bf3d35eb79e3e9a83d1.1712647788.git.linux@leemhuis.info

1 files changed, 18 insertions, 13 deletions

diff --git a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
index c999e40c79ab7f..06278501a4bdcc 100644
--- a/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
+++ b/Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst
@@ -136,8 +136,7 @@ will be considered the 'good' release and used to prepare the .config file.
 
 * **Segment 3**: perform and validate the bisection.
 
-  a) In case your 'broken' version is a stable/longterm release, add the Git
-     branch holding it::
+  a) Retrieve the sources for your 'bad' version::
 
        git remote set-branches --add stable linux-6.1.y
        git fetch stable
@@ -371,6 +370,21 @@ Preparations: set up everything to build your own kernels
 
   [:ref:`details<sources_bisref>`]
 
+.. _stablesources_bissbs:
+
+* Retrieve the sources for any stable or longterm series you might need.
+
+  Is the version you earlier established as 'bad' a stable or longterm release?
+  Then download the code for the series it belongs to ('linux-6.1.y' in this
+  example)::
+
+    git remote set-branches --add stable linux-6.1.y
+    git fetch stable
+
+  If the version earlier established as 'good' is from a different stable or
+  longterm series (say 6.0.13), repeat the previous step, but this time for the
+  branch holding the series the 'good' version belongs to (e.g. linux-6.0.y).
+
 .. _oldconfig_bissbs:
 
 * Start preparing a kernel build configuration (the '.config' file).
@@ -620,12 +634,10 @@ be a waste of time. [:ref:`details<introlatestcheck_bisref>`]
   reproduce it with the mainline kernel you just built? One that according to
   the `front page of kernel.org <https://kernel.org/>`_ is still supported? Then
   check if the latest codebase for the particular series might already fix the
-  problem. To do so, add the stable series Git branch for your 'good' kernel
-  (again, this here is assumed to be 6.0) and check out the latest version::
+  problem. To do so, check out that series latest version (again, this here is
+  assumed to be 6.0)::
 
     cd ~/linux/
-    git remote set-branches --add stable linux-6.0.y
-    git fetch stable
     git switch --discard-changes --detach linux-6.0.y
 
   Now use the checked out code to build and install another kernel using the
@@ -717,13 +729,6 @@ configuration created earlier this works a lot faster than many people assume:
 overall on average it will often just take about 10 to 15 minutes to compile
 each kernel on commodity x86 machines.
 
-* In case your 'bad' version is a stable/longterm release (say 6.1.5), add its
-  stable branch, unless you already did so earlier::
-
-    cd ~/linux/
-    git remote set-branches --add stable linux-6.1.y
-    git fetch stable
-
 .. _bisectstart_bissbs:
 
 * Start the bisection and tell Git about the versions earlier established as