Torstein Hegge [off-list ref] 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?
On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote:
Torstein Hegge [off-list ref] writes:
quoted
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.
From: Torstein Hegge <redacted>
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:
quoted
Torstein Hegge [off-list ref] writes:
quoted
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.
Thanks,
Christian.