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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> 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.

--
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]