Jeff King <peff@xxxxxxxx> writes: >> One possible use case might be when your repository is corrupt, and does >> not pass "git fsck" (without any argument). In such a case, if you are >> lucky and your disk corrupted objects only reachable from a recent topic >> branch, you might find that this command: >> >> $ git fsck master next ...list other topics here... >> >> still succeeds, so that you can figure out which topic makes such a >> limited fsck fail when it is listed on the command line, judge its >> importance and resurrect what you can from there, before nuking it to >> bring the repository back in health so that you can recreate the topic. > > Does that work? I had the impression from the documentation that the > arguments are purely about the reachability analysis, and that the > actual corruption/correctness checks actually look through the object db > directly, making sure each object is well-formed. Skimming cmd_fsck > seems to confirm that. You are right that you may see "corrupt object" for unreachable from the tips in the object store, but I was talking more about verifying everything that is needed for reachability analysis from the given tips can be read, iow, "missing object" errors, lack of which would mean you can salvage everything reachable from the refs involved in the traversal. -- 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