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

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

Reply via email to