On Thu, Sep 24, 2015 at 05:08:41PM -0700, Junio C Hamano wrote: > One thing I wondered was if we can reliably tell between a ref that > wanted to be a real ref that records a broken object name and a ref > that wanted to be a symbolic ref that points a bogus thing, and if > we can't, should we worry about it too much. The former is more > serious, as the history behind the commit it wanted to but failed to > record is at risk of being pruned. > > One case that is clearly safe is "ref: refs/heads/gone"; it is not > likely to be the result of attempting to write a real object name > gone bad by whatever filesystem corruption. On the other hand, an > obviously problematic case is an empty file. We cannot tell if the > "broken" ref used to anchor the tip of a real history (which is > about to be lost with Dscho's patch 1/4) or was merely pointing at > another ref (which will not harm the object database if ignored). > > So the rule should be > > If resolve_ref_unsafe_1() says it is a symbolic ref, if > check_ref_format() is OK with the ref it points at, and if that > pointee is missing, then it is safe to skip. > > All other funnies should trigger the safety. Right, I agree with that rule. If we don't know what it is, we should err on the conservative side (and that _shouldn't_ happen, because does not generate files in .git/refs that it cannot itself understand). But "ref: " is clearly something we understand. -Peff -- 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