From: Christian Couder <chriscool@tuxfamily.org>
Date: Thu, 05 Nov 2009 05:22:27 GMT
Subject: Re: [RFC/PATCH 0/3] use '--bisect-refs' as bisect rev machinery option
Message-ID: <200911050622.27159.chriscool@tuxfamily.org>
In-Reply-To: <7vtyxaez4f.fsf@alter.siamese.dyndns.org>

On Wednesday 04 November 2009, Junio C Hamano wrote:
> Christian Couder <chriscool@tuxfamily.org> writes:
> > So to do that you would use "git bisect start ..." and then you could
> > use:
> >
> > $ git rev-list --bisect HEAD --not $GOOD_COMMITS
> >
> > to get the commit that you would have to test if the current commit is
> > bad and:
> >
> > $ git rev-list --bisect  $BAD --not $GOOD_COMMITS HEAD
> >
> > to get the commit that you would have to test if the current commit is
> > good.
>
> Even in that case, the problem is still about narrowing the set of the
> current bisection graph.  If --bisect option implicitly grabs good and
> bad defined in the refspace like Linus's patch does, it will give you the
> same behaviour of the above two commands, no?

I think it will probably work when you add a good rev, but in the case where 
you give a different bad (the first command above) it does not work the 
same.

The test case in patch 1/3 shows that. It does:

git bisect start $HASH7 $HASH1 &&
...
rev_list2=$(git rev-list --bisect $HASH3 --not $HASH1) &&
test "$rev_list2" = "$HASH2" 

and that last command fails.

Best regards,
Christian.