On Mon, Apr 22, 2013 at 14:13:00 -0700, Junio C Hamano wrote: > Torstein Hegge <hegge@xxxxxxxxxxx> 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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html