Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option

From: Junio C Hamano <gitster@pobox.com>
Date: Nov 4, 2009, 19:22 UTC
Message-ID: <7veioegko3.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.LFD.2.01.0911041033530.31845@localhost.localdomain>

Linus Torvalds <torvalds@linux-foundation.org> writes:

Show 12 quoted lines

> On Wed, 4 Nov 2009, Linus Torvalds wrote:
>> 
>> Yes, it is a behavioral change, but is it a bad one?
>
> .. and perhaps we could introduce --bisect-refs as the "old behavior" of 
> '--bisect' to git rev-list?
>
> I kind of suspect that it is unlikely that people are using 'git rev-list 
> --bisect' while _inside_ a bisection, but then wanting to bisect someting 
> that is outside the set of commits we're currently actively bisecting.
>
> But maybe I'm wrong.

Maybe I'm wrong too, but I do not think that is plausible that people are doing nested bisection that way. It is probably a useful thing to do, but if somebody has thought of doing so we would have at least seen a request to add a way to tell "git-bisect" what names to use to record the good/bad set of commits under to make their implementation easier. I haven't, and I take it an indication that it is very implausible that such scripts by people exist to be broken by this change.

I was more worried about people who reinvented the wheel and are using their own git-bisect.sh derivative. It probably was forked from the version that still used 'git rev-list --bisect", manually feeding good and bad set of commits to it from the command line. But then what they are feeding would be the same as the new --bisect option implicitly gives them anyway, so there won't be a regression either.