Jon Seymour <jon.seymour@xxxxxxxxx> 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?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html