Jeff King <peff@xxxxxxxx> writes: > I recently ran into a situation where dealing with a corrupted > repository was more confusing than necessary, because Git by default > ignores corrupted refs in many commands. > > A while ago we introduced GIT_REF_PARANOIA, which works by including > broken refs in iteration, which then typically causes later operations > to fail (e.g., during repacking, you'd prefer to barf loudly when trying > to access the missing object rather than incorrectly assume the objects > from the broken ref aren't reachable). > > I think this is a better default for Git to have in general, not just > for a few select operations (we turn it on by default for pruning and > some repacks). We shouldn't see corruptions in general, and complaining > loudly when we do is the safest option. The reason we held back when the > knob was introduced was mostly out of deference to the historical > behavior. Yeah, having an escape hatch to serve as a tool to deal with and repair a corrupt repository might be worth considering, but I tend to agree that it is a better default to notice and loudly report a corruption. The series was a quite pleasant read. Thanks.
