Re: [PATCH 5/5] refs.c: drop curate_packed_refs

> When we delete a ref, we have to rewrite the entire
> packed-refs file. We take this opportunity to "curate" the
> packed-refs file and drop any entries that are crufty or
> broken.
>
> Dropping broken entries (e.g., with bogus names, or ones
> that point to missing objects) is actively a bad idea, as it
> means that we lose any notion that the data was there in the
> first place. Aside from the general hackiness that we might
> lose any information about ref "foo" while deleting an
> unrelated ref "bar", this may seriously hamper any attempts
> by the user at recovering from the corruption in "foo".
>
> They will lose the sha1 and name of "foo"; the exact pointer
> may still be useful even if they recover missing objects
> from a different copy of the repository. But worse, once the
> ref is gone, there is no trace of the corruption. A
> follow-up "git prune" may delete objects, even though it
> would otherwise bail when seeing corruption.
>
> We could just drop the "broken" bits from
> curate_packed_refs, and continue to drop the "crufty" bits:
> refs whose loose counterpart exists in the filesystem. This
> is not wrong to do, and it does have the advantage that we
> may write out a slightly smaller packed-refs file. But it
> has two disadvantages:
>
>   1. It is a potential source of races or mistakes with
>      respect to these refs that are otherwise unrelated to
>      the operation. To my knowledge, there aren't any active
>      problems in this area, but it seems like an unnecessary
>      risk.
>
>   2. We have to spend time looking up the matching loose
>      refs for every item in the packed-refs file. If you
>      have a large number of packed refs that do not change,
>      that outweights the benefit from writing out a smaller