All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stephan Beyer <s-beyer@gmx.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Christian Couder <chriscool@tuxfamily.org>
Subject: Re: [PATCH 01/16] bisect: write about `bisect next` in documentation
Date: Sat, 27 Feb 2016 20:38:59 +0100	[thread overview]
Message-ID: <56D1FB53.2020404@gmx.net> (raw)
In-Reply-To: <xmqqk2lqghdw.fsf@gitster.mtv.corp.google.com>

Hi,

On 02/27/2016 07:03 PM, Junio C Hamano wrote:
> Stephan Beyer <s-beyer@gmx.net> writes:
> 
>> This command is also handy when you accidentally checked out another
>> commit during a bisection. It computes the commit for the bisection
>> and checks it out again.
>>
>> -->8-->8-->8--
>>
>> Is that better?
> 
> Thanks, I think it is definitely better than the original patch.
> 
> I cannot say it is better than not having that extra paragraph,
> though.

Okay, I will remove that extra paragraph.

However, it probably should be documented what "git bisect next" does
after you've specified bad and good commits.

For that, I'd like to have an extra informational paragraph.
What about: "In general, the command computes the next commit for the
bisection and checks it out."
This would be neutral, in the meaning that no use case is involved.

Another more "strict" choice could be to change the behavior such that
"git bisect next" dies when invoked after a good (and a bad) commit is
specified. In that case, there is no need to document the behavior ;-)
However, in that case the name of "git bisect next" would be wrong...

Cheers,
Stephan

  reply	other threads:[~2016-02-27 19:39 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-26  2:04 [PATCH 00/16] git bisect improvements Stephan Beyer
2016-02-26  2:04 ` [PATCH 01/16] bisect: write about `bisect next` in documentation Stephan Beyer
2016-02-26  8:02   ` Jacob Keller
2016-02-26 18:47   ` Junio C Hamano
2016-02-27 13:45     ` Stephan Beyer
2016-02-27 18:03       ` Junio C Hamano
2016-02-27 19:38         ` Stephan Beyer [this message]
2016-02-28 18:28           ` Junio C Hamano
2016-02-26  2:04 ` [PATCH 02/16] bisect: add test for the bisect algorithm Stephan Beyer
2016-02-26  6:53   ` Christian Couder
2016-02-26 21:38     ` Stephan Beyer
2016-02-27 11:40       ` Christian Couder
2016-02-27 12:42         ` Matthieu Moy
2016-02-26  2:04 ` [PATCH 03/16] bisect: make bisect compile if DEBUG_BISECT is set Stephan Beyer
2016-02-26  2:04 ` [PATCH 04/16] bisect: make algorithm behavior independent of DEBUG_BISECT Stephan Beyer
2016-02-26  2:04 ` [PATCH 05/16] bisect: get rid of recursion in count_distance() Stephan Beyer
2016-02-26  2:04 ` [PATCH 06/16] bisect: use struct node_data array instead of int array Stephan Beyer
2016-02-26  2:04 ` [PATCH 07/16] bisect: replace clear_distance() by unique markers Stephan Beyer
2016-02-26  2:04 ` [PATCH 08/16] bisect: use commit instead of commit list as arguments when appropriate Stephan Beyer
2016-02-26  3:10   ` Junio C Hamano
2016-02-26  2:04 ` [PATCH 09/16] bisect: extract get_distance() function from code duplication Stephan Beyer
2016-02-26  2:04 ` [PATCH 10/16] bisect: introduce distance_direction() Stephan Beyer
2016-02-26  2:04 ` [PATCH 11/16] bisect: make total number of commits global Stephan Beyer
2016-02-26  2:04 ` [PATCH 12/16] bisect: rename count_distance() to compute_weight() Stephan Beyer
2016-02-26  2:04 ` [PATCH 13/16] bisect: prepare for different algorithms based on find_all Stephan Beyer
2016-02-26  2:04 ` [PATCH 14/16] bisect: use a modified breadth-first search to find relevant weights Stephan Beyer
2016-02-26  3:09   ` Junio C Hamano
2016-02-26 20:55     ` Stephan Beyer
2016-02-26  2:04 ` [PATCH 15/16] bisect: compute best bisection in compute_relevant_weights() Stephan Beyer
2016-02-26  2:04 ` [PATCH 16/16] bisect: get back halfway shortcut Stephan Beyer
2016-03-20 18:50 ` [PATCH 00/16] git bisect improvements Pranit Bauva
2016-03-21 22:22   ` Stephan Beyer
2016-03-22  7:35     ` Christian Couder
2016-03-22 11:35     ` Pranit Bauva

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=56D1FB53.2020404@gmx.net \
    --to=s-beyer@gmx.net \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.