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. Thanks, Christian. -- 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
