Am 24.07.2011 07:57, schrieb Jon Seymour: > Currently git bisect assumes that the respository to be undamaged. This limits the usefulness > of git bisect when working with damaged repositories. So, what? Isn't a broken repository also (almost) useless w.r.t. log, checkout, rebase, reset, push, fetch...? > This series introduces an option, --ignore-checkout-failure, which can be used with > "git bisect start" to indicate that checkout failures should be tolerated for the life > of the (new) bisection process. This allows git bisect to be used on damaged repositories. In > particular, it allows git bisect to be used to locate commits containing damaged trees. I have to wonder: why do you care only about git-bisect? If you want to be able to use a broken repository, aren't there many more commands that fail and for which you also want to have a similar work-around? Or is git-bisect the only one where the work-around was missing? > If the --ignore-checkout-failure option is specified, then if git checkout fails either > at the start of the bisection process or later while probing a new trial commit, then the > checkout failure will be noisily ignored and the HEAD reference will be updated to the > intended commit. This may leave the working tree and index in an inconsistent state > w.r.t the HEAD commit. But what is an inconsistent state good for? In general, it makes no sense to decide whether the result is "good" or "bad" when you know in advance that the checked-out state is inconsistent. -- 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