Re: [PATCH 4/4] gc: remove broken refs
- From
Jeff King <peff@peff.net>
- Date
- Sep 25, 2015, 01:35 UTC
- Message-ID
- <20150925013537.GA7522@sigill.intra.peff.net>
- In-Reply-To
- <xmqqr3lnuzqu.fsf@gitster.mtv.corp.google.com>
On Thu, Sep 24, 2015 at 05:08:41PM -0700, Junio C Hamano wrote:
Show 22 quoted lines
> 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