Re: [RFC 0/9] bisect: allow git bisect to be used with repos containing damaged trees.

[Junio C Hamano <gitster@pobox.com>]

Jon Seymour <jon.seymour@gmail.com> writes:

> ... In particular, it
> allows git bisect to be used to locate commits containing damaged trees.

I am afraid it wouldn't allow it, and I am not going to take this series
that adds an option to bisect to ignore errors during checkout.

Remember that bisection is to find a single event in the history whose
effect consistently persists in all the commits into the future from that
point.  For example, if you have this history:

    ---A---B---C

and there is a bitflip in a blob contained in the commit B's tree, you may
not be able to check it out. But that does _not_ mean you cannot check C
out due to a corrupt object in B. The change going from B to C may be to
remove that blob, for example. "A tree that refers to a corrupt object was
introduced by this commit" is not a single event whose effect cascades
through the history into the future [*1*].

Besides, if you have a corrupt commit, your history traversal may not even
be correct, as we won't be reading its parent pointers correctly.

Having said that, an option to bisect that does _not_ touch the index nor
the working tree at all may be a useful thing to have. The test you want
to run on the candidate revisions bisect suggests may not need a working
tree (e.g. it may be built around "git grep -e foo $revision -- $path"),
and it may work just as well for the bisection you wanted to do in your
broken repository.

[Footnote]

*1* Theoretically, you could turn it into such by using a test that wants
to traverse and verify all the objects reachable from the candidate
commit, e.g.

    $ git rev-list --objects $rev | git pack-objects --stdout >/dev/null

which would succeed on A, and fail on B and all the commits that reach B,
including C. Was that what you had in mind?