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 14:45:23 +0100	[thread overview]
Message-ID: <56D1A873.1090709@gmx.net> (raw)
In-Reply-To: <xmqqoab3jokp.fsf@gitster.mtv.corp.google.com>

Hi,

On 02/26/2016 07:47 PM, Junio C Hamano wrote:
> But I wonder if it is safe and sane to encourage "checking out other
> branches during a bisect session." as you cannot tell what other
> crazy things they will do while on "other branches".  I do not think
> we even try to (and I do not think we should) handle a case where
> the user tries to merge another branch, sees conflicts and says
> "bisect next" without cleaning up, for example.

I rephrase it as follows to not encourage checking out another branch
(or commit ;]) but to mention that it works to get back if someone
accidentally did it.

--8<--8<--8<--

Bisect next
~~~~~~~~~~~

In case you have marked a commit as bad but you do not know a good
commit, you do not have to crawl through the commit history yourself to
find a good commit. Simply issue the command:

------------
$ git bisect next
------------

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

  reply	other threads:[~2016-02-27 13:48 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 [this message]
2016-02-27 18:03       ` Junio C Hamano
2016-02-27 19:38         ` Stephan Beyer
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=56D1A873.1090709@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.