Jeff King <peff@xxxxxxxx> writes: > I was tempted to just drop this section entirely. It's mostly redundant > with the DESCRIPTION section, and any extra details could be folded in > there. The most useful bit is the "what do you do when there is > corruption". But that should perhaps get its own section, if somebody > feels like writing something more detailed (I thought we had a guide > somewhere, but I couldn't find it). 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. -- 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