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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Apr 25, 2013, 04:26 UTC
Message-ID: <20130425.062632.630918480810226803.chriscool@tuxfamily.org>
In-Reply-To: <20130422222058.GF5650@pvv.ntnu.no>

From: Torstein Hegge <hegge@resisty.net>
Subject: Re: [PATCH] bisect: Store first bad commit as comment in log file
Date: Tue, 23 Apr 2013 00:20:58 +0200

Show 16 quoted lines

> 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.

Yeah, I think it is a good enough reason for your patch.

Show 5 quoted lines

> 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.

Yeah, I agree.

> 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.

I think your arguments are good enough.

Thanks, Christian.