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

From: Christian Couder <chriscool@tuxfamily.org>
Date: Nov 5, 2009, 05:22 UTC
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:

Show 18 quoted lines

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