Jon Seymour <jon.seymour@xxxxxxxxx> writes: > I don't think you understood my intention. Suppose, I have > > B4 - B5 - B6' - B7' - B8' - B9 > > such that B6 and B7 and B8 all contain a damaged tree, but B4, B5 and B9 don't > since it contains a different tree, then: What prevents your disk from corrupting a blob that was in B6, modified by commit B7, and then _reverted_ by commit B8? Then your checkout would fail at B6 and B8 but B7 will be fine. As I wrote in my footnote, if your test is to find the most recent commit, starting from which all the objects reachable from it are not corrupt (by using "rev-list --objects $commit | pack-objects"), you could run your bisect by somehow first finding a good commit (B5) that passes the test, and after knowing a bad commit (B8) that does not pass (because it is missing the single blob that is unreadable for B6 and B8), and then bisect using a slightly less expensive test rev-list --objects B5..$commit | pack-objects to find it in theory, but "Being unable to check-out" is not an isolated event and cannot be used as the check as you seem to think. >> 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. > > I am happy to do this, since clearly enables a superset of the cases > handled by --ignore-checkout-failure. > > I propose to do this with a new ref (perhaps BISECT_CURSOR) which will > be used in place of HEAD for the purposes of driving the bisection > algorithm if --no-checkout has been specified on the git bisect start > command. Pros of using HEAD (i.e. the only change under the new mode would be that we do not touch the index nor the working tree) is that the test you would need to run in each step of bisection can use the familiar HEAD ref instead of a strange BISECT_CURSOR, "bisect reset" will take you back from the tentative detached HEAD state the usual way, and most likely the necessary change to git-bisect.sh would be smaller. Cons of using HEAD would be that the index and the working tree will be totally out-of-sync with respect to HEAD during the bisection (by definition---as that is the point of this new mode). One could argue that a naïve user might get confused, but I am not sure how big a practical downside it would be. -- 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