Re: [PATCH 1/9 v4] bisect: add "git bisect replace" subcommand

From: Christian Couder <chriscool@tuxfamily.org>
Date: Nov 14, 2008, 09:34 UTC
Message-ID: <200811141034.06282.chriscool@tuxfamily.org>
In-Reply-To: <491C58A3.2000609@gnu.org>

Le jeudi 13 novembre 2008, Paolo Bonzini a écrit :

Show 14 quoted lines

> > Of course it also depends on how often people use "git bisect", but it
> > seems that there are people out there bisecting very frequently and
> > that these people care very much about bisectability of the tree.
>
> What about "git bisect cherry-pick COMMIT" which would do a "cherry-pick
> -n" of COMMIT after every bisection unless COMMIT is in the ancestry of
> the current revision?  So if you have to bisect between A and B, and you
> know that a bug present between A and B was fixed by C, you could do
>
>   git bisect good A
>   git bisect bad B
>   git bisect cherry-pick C
>
> This would subsume Junio's proposal:

Yes, it looks better than Junio's, except when there is no existing commit that perfectly works.

> users could also set up a few 
> special bisect/set-debug-to-1, bisect/remove-cflags-o2 and so on patches
> that you could use for purposes other than ensuring known bugs are fixed.

In this case it is similar to Junio's proposal. But I think that for changes like set-debug-to-1 and remove-cflags-o2, using the right make command should be enough.

> Finally, you could have a [bisect] configuration section with entries
> like "cherry-pick = BROKEN-SHA1 FIX-SHA1" and "git bisect" would apply
> FIX-SHA1 automatically if the bisect tip were in BROKEN-SHA1..FIX-SHA1.

Yes, but how do you share this between members of a team?

Your proposal and Junio's proposal also don't use real sha1 names for commits that are tested, so it's more difficult to talk about them, share them, use them, ...

Regards, Christian.