Re: [PATCH] bisect: Store first bad commit as comment in log file

[Torstein Hegge <hegge@resisty.net>]

On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
> Torstein Hegge <hegge@resisty.net> writes:
> 
> > I took another look at this. I wasn't able to come up with anything
> > useful for the "The merge base $rev is bad" case, but for the "only
> > skipped commits left to test" case one could do something like this.
> 
> We skipped them because we can gain _no_ information from testing
> these commits. They are not even "possibly bad", but are "unknown".
> 
> So it feels to me that by definition listing them would not be
> useful. What am I missing?

The information lies in that those commits are the only commits with an
unknown state. So if the bisecter hands off the bisect log to someone
else when they can't test further, the current status is recorded.

I think part of the reason I started looking at this is that there are
no good way to see what git said after the previous 'git bisect
good/bad' if the terminal output is lost. And lost terminal output is
fairly likely if you are bisecting something that requires reboots for
each test.

But I don't feel very strongly about this. It was based on Christian's
idea, so unless he comes up with some compelling arguments I'll drop it.