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

doc: git bisect: clarify the usage of the synopsis vs actual command 

The difference between a synopsis and an actual command is that the synopsis
is a more abstract representation of the command, which may include
placeholders for arguments and options. The actual command is the specific
instance of the command with all the arguments and options filled in.

The formatting of an actual command is a code block, with the command
prefixed by a dollar sign ($) to indicate that it is a command to be run in
the terminal. It can also include comments with a hash sign (#) to explain
the command or provide additional information, just like in a regular
terminal session.

Signed-off-by: Jean-Noël Avila <jn.avila@free.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
main
Jean-Noël Avila 2026-05-25 10:28:23 +00:00 committed by Junio C Hamano
parent 50cd5219d2
commit ed31e2872a
1 changed files with 9 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
Documentation/git-bisect.adoc
View File

@ -96,9 +96,8 @@ Bisect reset
After a bisect session, to clean up the bisection state and return to
the original `HEAD`, issue the following command:

------------------------------------------------
$ git bisect reset
------------------------------------------------
[synopsis]
git bisect reset

By default, this will return your tree to the commit that was checked
out before `git bisect start`. (A new `git bisect start` will also do
@ -108,7 +107,8 @@ With an optional argument, you can return to a different commit
instead:

[synopsis]
$ git bisect reset <commit>
git bisect reset <commit>


For example, `git bisect reset bisect/bad` will check out the first
bad revision, while `git bisect reset HEAD` will leave you on the
@ -174,13 +174,13 @@ For example, if you are looking for a commit that introduced a
performance regression, you might use

------------------------------------------------
git bisect start --term-old fast --term-new slow
$ git bisect start --term-old fast --term-new slow
------------------------------------------------

Or if you are looking for the commit that fixed a bug, you might use

------------------------------------------------
git bisect start --term-new fixed --term-old broken
$ git bisect start --term-new fixed --term-old broken
------------------------------------------------

Then, use `git bisect <term-old>` and `git bisect <term-new>` instead
@ -328,11 +328,10 @@ Bisect run
If you have a script that can tell if the current source code is good
or bad, you can bisect by issuing the command:

------------
$ git bisect run my_script arguments
------------
[synopsis]
git bisect run <cmd> [<arg>...]

Note that the script (`my_script` in the above example) should exit
Note that _<cmd>_ run with _<arg>_ should exit
with code 0 if the current source code is good/old, and exit with a
code between 1 and 127 (inclusive), except 125, if the current source
code is bad/new.