Re: [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.

[Michael J Gruber <git@drmicha.warpmail.net>]

David J. Mellor venit, vidit, dixit 19.03.2009 08:00:
> 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:
> 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.

>  ------------
> +$ 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
>  --------