All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
@ 2009-03-19  7:00 David J. Mellor
  2009-03-19 10:12 ` Michael J Gruber
  0 siblings, 1 reply; 2+ messages in thread
From: David J. Mellor @ 2009-03-19  7:00 UTC (permalink / raw)
  To: gitster; +Cc: git

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

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* Re: [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
  2009-03-19  7:00 [PATCH] Documentation: reworded the "Description" section of git-bisect.txt David J. Mellor
@ 2009-03-19 10:12 ` Michael J Gruber
  0 siblings, 0 replies; 2+ messages in thread
From: Michael J Gruber @ 2009-03-19 10:12 UTC (permalink / raw)
  To: David J. Mellor; +Cc: gitster, git

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-03-19 10:14 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-19  7:00 [PATCH] Documentation: reworded the "Description" section of git-bisect.txt David J. Mellor
2009-03-19 10:12 ` Michael J Gruber

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.