Re: [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
David J. Mellor venit, vidit, dixit 19.03.2009 08:00:
Show 29 quoted lines
> Added fixes missing from 2364259.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 51d06c1..1a4a527 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -114,21 +114,22 @@ $ git bisect view --stat
> Bisect log and bisect replay
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -The good/bad input is logged, and:
> +After having marked revisions as good or bad, then:
>
> ------------
> $ git bisect log
> ------------
>
> -shows what you have done so far. You can truncate its output somewhere
> -and save it in a file, and run:
> +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:
>
I guess his tells me that I should not have taken the following (http://article.gmane.org/gmane.comp.version-control.git/113568) literally:
David J. Mellor venit, vidit, dixit 18.03.2009 03:54:
Show 17 quoted lines
> On 03/17/2009 02:18 AM, Michael J Gruber wrote:
>> One minor reoccurring issue is the following type of construct:
>>
>> ###
>> The good/bad input is logged, and:
>>
>> ------------
>> $ git bisect log
>> ------------
>>
>> shows what you have done so far.
>> ###
>>
>> The first line is not a complete sentence.
>
> I agree. I will send a revised patch (patch 2 in this sequence) that
> corrects this.
Again, I think the patch improves the documentation nicely, I just don't think that construct is helpful.
Show 37 quoted lines
> ------------
> +$ git bisect reset
> $ git bisect replay that-file
> ------------
>
> -if you find later that you made a mistake specifying revisions as good/bad.
> -
> Avoiding testing a commit
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> @@ -141,7 +142,7 @@ want to find a nearby commit and try that instead.
> For example:
>
> ------------
> -$ git bisect good/bad # previous round was good/bad.
> +$ git bisect good/bad # previous round was good or bad.
> Bisecting: 337 revisions left to test after this
> $ git bisect visualize # oops, that is uninteresting.
> $ git reset --hard HEAD~3 # try 3 revisions before what
> @@ -149,7 +150,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
> ------------
>
> Then compile and test the chosen revision. Afterwards the revision
> -is marked as good/bad in the usual manner.
> +is marked as good or bad in the usual manner.
>
> Bisect skip
> ~~~~~~~~~~~~
> @@ -240,7 +241,7 @@ before compiling, run the real test, and afterwards decide if the
> revision (possibly with the needed patch) passed the test and then
> rewind the tree to the pristine state. Finally the script should exit
> with the status of the real test to let the "git bisect run" command loop
> -to determine the eventual outcome of the bisect session.
> +determine the eventual outcome of the bisect session.
>
> EXAMPLES
> --------
David J. Mellor