On Mon, Sep 19, 2011 at 02:38:41PM -0700, Junio C Hamano wrote: > Yeah, I've been thinking about making it an error to give refs to fsck, as > I do not think the use cases for feature justifies the possible confusion > it may cause. > > 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. -Peff -- 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