Thread (1 message) 1 message, 1 author, 2022-05-06

Re: [PATCH v2 2/2] bisect: output bisect setup status in bisect log

From: Junio C Hamano <hidden>
Date: 2022-05-06 16:57:13

Taylor Blau [off-list ref] writes:
On Fri, May 06, 2022 at 01:52:54AM +0100, Chris Down wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help