Re: [PATCH 4/4] gc: remove broken refs

[Jeff King <peff@peff.net>]

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