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

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

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?