On Tue, Mar 17, 2015 at 3:31 AM, Jeff King <peff@xxxxxxxx> wrote: > 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 s/outweights/outweighs/ > packed-refs file (it doesn't get smaller, and you do a > bunch of directory traversal to find that out). > > Signed-off-by: Jeff King <peff@xxxxxxxx> -- 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