Junio C Hamano wrote: > A tl;dr is that we _trust_ our refs and everything reachable from > them has to be complete. If that is not the case, things will not > work, and it is not a priority to add workarounds in the normal > codepath to slow things down. Makes sense. > That does not forbid an addition of "git recover-corrupted-repo" > command, whose "assume everything might be broken" code is not > shared with the fastpath of other commands. I'm not looking for a kitchen-sink command: I'm looking for a well-documented toolset to precisely fix corruptions. We have some corruption tests in our testsuite already: I think I'll start digging there. Thanks. -- 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