David J. Mellor venit, vidit, dixit 20.03.2009 04:35: > Reworded to avoid splitting sentences across examples of command usage. > > Signed-off-by: David J. Mellor <dmellor@xxxxxxxxxxxxxxxx> > --- > Documentation/git-bisect.txt | 44 ++++++++++++++++++++++------------------- > 1 files changed, 24 insertions(+), 20 deletions(-) > > diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt > index 1a4a527..93d9fc0 100644 > --- a/Documentation/git-bisect.txt > +++ b/Documentation/git-bisect.txt > @@ -50,28 +50,29 @@ $ git bisect good v2.6.13-rc2 # v2.6.13-rc2 was the last version > ------------------------------------------------ > > When you have specified at least one bad and one good version, the > -command bisects the revision tree and outputs something similar to: > +command bisects the revision tree and outputs something similar to > +the following: > > ------------------------------------------------ > Bisecting: 675 revisions left to test after this > ------------------------------------------------ > > -and then checks out the state in the middle. You would now compile > -that kernel and boot it. If the booted kernel works correctly, you > -would then issue the following command: > +The state in the middle of the set of revisions is then checked out. > +You would now compile that kernel and boot it. If the booted kernel > +works correctly, you would then issue the following command: > > ------------------------------------------------ > $ git bisect good # this one is good > ------------------------------------------------ > > -which would then output something similar to: > +The output of this command would be something similar to the following: > > ------------------------------------------------ > Bisecting: 337 revisions left to test after this > ------------------------------------------------ > > -and you continue along, compiling that one, testing it, and depending > -on whether it is good or bad issuing the command "git bisect good" > +You keep repeating this process, compiling the tree, testing it, and > +depending on whether it is good or bad issuing the command "git bisect good" > or "git bisect bad" to ask for the next bisection. > > Eventually there will be no more revisions left to bisect, and you > @@ -81,7 +82,7 @@ Bisect reset > ~~~~~~~~~~~~ > > To return to the original head after a bisect session, you issue the > -command: > +following command: > > ------------------------------------------------ > $ git bisect reset > @@ -94,14 +95,14 @@ the bisection state). > Bisect visualize > ~~~~~~~~~~~~~~~~ > > -During the bisection process, you issue the command: > +To see the currently remaining suspects in 'gitk', the following command > +is issued during the bisection process: > > ------------ > $ git bisect visualize > ------------ > > -to see the currently remaining suspects in 'gitk'. `view` may also > -be used as a synonym for `visualize`. > +`view` may also be used as a synonym for `visualize`. > > If the 'DISPLAY' environment variable is not set, 'git log' is used > instead. You can also give command line options such as `-p` and > @@ -114,16 +115,17 @@ $ git bisect view --stat > Bisect log and bisect replay > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > -After having marked revisions as good or bad, then: > +After having marked revisions as good or bad, you issue the following > +command to show what has been done so far: > > ------------ > $ git bisect log > ------------ > > -shows what you have done so far. If you discover that you made a mistake > -in specifying the status of a revision, you can save the output of this > -command to a file, edit it to remove the incorrect entries, and then issue > -the following commands to return to a corrected state: > +If you discover that you made a mistake in specifying the status of a > +revision, you can save the output of this command to a file, edit it to > +remove the incorrect entries, and then issue the following commands to > +return to a corrected state: > > ------------ > $ git bisect reset > @@ -173,8 +175,8 @@ using the "'<commit1>'..'<commit2>'" notation. For example: > $ git bisect skip v2.5..v2.6 > ------------ > > -would mean that no commit between `v2.5` excluded and `v2.6` included > -can be tested. > +The effect of this would be that no commit between `v2.5` excluded and > +`v2.6` included could be tested. > > Note that if you also want to skip the first commit of the range you > would issue the command: > @@ -183,14 +185,16 @@ would issue the command: > $ git bisect skip v2.5 v2.5..v2.6 > ------------ > > -and the commit pointed to by `v2.5` would also be skipped. > +This would cause the commits between `v2.5` included and `v2.6` included > +to be skipped. > + > > Cutting down bisection by giving more parameters to bisect start > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > You can further cut down the number of trials, if you know what part of > the tree is involved in the problem you are tracking down, by specifying > -path parameters when issuing the `bisect start` command, like this: > +path parameters when issuing the `bisect start` command: > > ------------ > $ git bisect start -- arch/i386 include/asm-i386 Thanks :) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
