From: Torstein Hegge <he...@resisty.net>
Subject: Re: [PATCH] bisect: Store first bad commit as comment in log file
Date: Tue, 23 Apr 2013 00:20:58 +0200
> On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
>> Torstein Hegge <he...@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.
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html