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.
> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html