On Sun, Jul 24, 2011 at 6:05 PM, Johannes Sixt <j6t@xxxxxxxx> wrote: > 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...? > The broken or missing commits in a broken repository are useless, but all the other commits and the things they reach may still be useful. When trying to recover such things, git bisect could be a useful tool, since it would allow one to automate discovery of the broken regions of the graph. Once the broken regions have been isolated, grafts can be used to cauterize the damaged regions, the remainder can be rescued with git-filter-branch and life goes on. >> 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? > git bisect is, in principle, a very useful tool for identifying regions of damage in a broken repo. I don't want to have to write another tool that does exactly what git bisect does except for the checkout function which, for the purpose of repo rescue, I do not need. > > 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. > The inconsistent state is useful because I can use that state to progress the bisection. In particular, I can write a test which checks to see whether this particular commit is broken (can't reach its parents or its tree). In fact, git status does just nicely for this purpose. And by using that test with git bisect I can discover the precise boundaries of the broken regions of the graph. Of course, I have no intention of doing any kind of development with a repo in that state - the point is to only to make an existing tool even more useful - by helping it deal with broken repos too. jon. -- 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