Re: Article about "git bisect run" on LWN

From: Christian Couder <chriscool@tuxfamily.org>
Date: Feb 10, 2009, 06:12 UTC
Message-ID: <200902100712.31820.chriscool@tuxfamily.org>
In-Reply-To: <ee77f5c20902091303v1d268761ufdc85e2364097d84@mail.gmail.com>

Le lundi 9 février 2009, David Symonds a écrit :

Show 11 quoted lines

> On Tue, Feb 10, 2009 at 12:15 AM, Johannes Schindelin
>
> <Johannes.Schindelin@gmx.de> wrote:
> > I think Junio meant using '< $file' type redirection, to avoid an
> > unnecessary fork().  (Good habit, avoiding fork()s...)
>
> Yes, I usually pass filenames to grep; this time I was
> copy-and-pasting parts of the original script. But my point still
> remains: it seems it would be cleaner to do this kind of
> always-good-filtering in the test script rather than make git-bisect
> more complex.

But it's not so easy and not efficient to do this kind of filtering in the test script.

Maybe something cleaner could be to have "always good" and "always skipped" refs that are automatically used each time you bisect.

For example, "git bisect good --always" and "git bisect skip --always" could add refs in "refs/bisect/always/" even when you are not bisecting, and these refs would not be removed on reset.

But in the end, I think this does not really fix the problem. If you need such hacks, it means that your commit DAG is not easily bisectable. For example if you must skip too many commits, then too often bisection will not be able to point to a first bad commit because it won't be able to tell between many skipped commits.

That's why I think the proper fix is to have a way to bisect on a fixed up commit DAG where you can just get rid of old annoying bugs and of history parts that are not relevant.

Regards, Christian.