git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Taylor Blau <me@ttaylorr.com>
Cc: Chris Down <chris@chrisdown.name>,
	git@vger.kernel.org,
	Johannes Schindelin <johannes.schindelin@gmx.de>,
	Christian Couder <chriscool@tuxfamily.org>,
	kernel-team@fb.com
Subject: Re: [PATCH v2 2/2] bisect: output bisect setup status in bisect log
Date: Fri, 06 May 2022 09:57:03 -0700	[thread overview]
Message-ID: <xmqq7d6yoazk.fsf@gitster.g> (raw)
In-Reply-To: <YnSQDzhNjmu5ws4f@nand.local> (Taylor Blau's message of "Thu, 5 May 2022 23:03:43 -0400")

Taylor Blau <me@ttaylorr.com> writes:

> On Fri, May 06, 2022 at 01:52:54AM +0100, Chris Down wrote:
>> This allows seeing the current intermediate status without adding a new
>> good or bad commit:
>>
>>     $ git bisect log | tail -1
>>     # status: waiting for bad commit, 1 good commit known
>
> Hmm. I was worried that this would make it harder to turn the output of
> "git bisect log" into something you can inject into "git bisect replay
> <log>". But it doesn't, because you prefix the status lines with a '#'
> character.

;-) 

It has always been the basic design of "git bisect replay" since the
old days back when the command was scripted.  The log is designed to
be an executable shell script and we do not need to use "replay" at
all.

> I'm not totally convinced it _needs_ to live in "git bisect log",

It is a convenient place and other "helpful" comments are also
stored there, so the existing users may already know to look into it
to reorient where they were.

The original suggestion during the previous round of this series was
to come up with a way to help those who get lost during a long
session of spelunking the history to start bisection, like so:

 * start a bisection session
 * find one end (perhaps bad end)
 * say "git bisect bad $this" and be told "now go find a good one"
 * ran around various versions with "git reset --hard $that &&
   make" to see the other end (perhaps good end).
 * forget where they were---was it their turn to feed a good
   revision or bad revision?
 * "git bisect status" can be used to remind them that they were
   told "now go find a good one".

And I actually find that "go to log and see what progress you made
so far" as implemented in this series a far easier and scalable
solution than "git bisect status".  Next time we add more "here is
an extra piece of information to help reorient yourself", we do not
have to worry about how to present it in "git bisect status" output
(and we do not have to worry about teaching "bisect status"
subcommand about it in the first place).  As long as we make sure
that everybody uses the new "bisect_log_printf()" wrapper for
informational messages, we get it for free.

Thanks.

  parent reply	other threads:[~2022-05-06 16:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-06  0:52 [PATCH v2 0/2] bisect: status improvements when bisect is not fully fleshed out Chris Down
2022-05-06  0:52 ` [PATCH v2 1/2] bisect: output state before we are ready to compute bisection Chris Down
2022-05-06  2:52   ` Taylor Blau
2022-05-06 10:14     ` Chris Down
2022-05-06 16:42     ` Junio C Hamano
2022-05-06 18:12   ` Junio C Hamano
2022-05-06  0:52 ` [PATCH v2 2/2] bisect: output bisect setup status in bisect log Chris Down
2022-05-06  3:03   ` Taylor Blau
2022-05-06 10:09     ` Chris Down
2022-05-09 15:41       ` Taylor Blau
2022-05-06 16:57     ` Junio C Hamano [this message]
2022-05-06 16:47   ` Junio C Hamano
2022-05-06 18:18   ` Junio C Hamano
2022-05-09 15:43     ` Taylor Blau
2022-05-09 16:08       ` Junio C Hamano
2022-05-09 16:27         ` Taylor Blau
2022-05-07 10:58 ` [PATCH v2 0/2] bisect: status improvements when bisect is not fully fleshed out Chris Down
2022-05-07 18:25   ` Junio C Hamano
2022-05-07 21:22     ` Chris Down

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=xmqq7d6yoazk.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=chris@chrisdown.name \
    --cc=chriscool@tuxfamily.org \
    --cc=git@vger.kernel.org \
    --cc=johannes.schindelin@gmx.de \
    --cc=kernel-team@fb.com \
    --cc=me@ttaylorr.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).