Am 25.07.2011 11:28, schrieb Jon Seymour: > On Mon, Jul 25, 2011 at 4:35 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: >> 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. > > Understand that you don't wish to accept the series, but I do think > you are mistaken about whether it will work. > >> >> 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*]. > > 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: > > git bisect start B8' B4 --ignore-checkout-failure && > git bisect run eval "git status >/dev/null 2>&1 || false" > > will stop with bisect/bad = B6' > > This is exactly the result I wanted, and I discover B6' with a binary > search, rather than a linear search. > > (I could also discover B8' with a binary search by reversing the sense > of the test). The fundamental preconditions of bisection are: that there is a single event in the sequence, and that the effects of the event propagate to the end of the sequence. Junio explainded, that the second precondition is violated. Therefore, you cannot apply git-bisect to find brokenness in a repository *in general*. Of course, there may be special cases where stronger assumptions are justifiable, and your case may have been one of them. -- Hannes -- 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