Re: [RFC/PATCH 0/3] silence missing-link warnings in some cases

From: Junio C Hamano <gitster@pobox.com>
Date: Jun 1, 2015, 16:11 UTC
Message-ID: <xmqq7frn8l2r.fsf@gitster.dls.corp.google.com>
In-Reply-To: <20150601154103.GA14538@peff.net>

Jeff King <peff@peff.net> writes:

Show 8 quoted lines

>> The fixes make sense to me (I haven't carefully read the
>> implementation, but design/approach explained in the proposed log
>> messages are very sound), and I think 3/3 is a good thing to do,
>> too, in the new world order after d3038d2.
>
> I think it's rather the opposite. In a post-d3038d2 world, a missing
> object is _more_ likely to be a real corruption, and we would probably
> prefer to complain about it. I am on the fence though.

Sorry, but I wasn't talking about that far in the future.

In the immediate future that necessitates patches 1 and 2, a warning on such a missing object from the codepath in 3 would be equally annoying noise, no? And a purely post-d3038d2 world, all of these warnings may be pointing at a real corruption, as you referred to as "yet another possibility".

As you said, these should have been part of ignore-missing-links, so I'd say we should treat the codepaths that special case the callers that pass that option the same way.

Having said all that, I do not think it is healthy to assume that pre-d3038d2 prune is the only thing that may leave an incomplete and unreachable island of objects in the repository (two easy ways to do so are to interrupt unpack-objects or the commit walker dumb fetch). So from that point of view, these three patches are reasonable things to keep even in the longer term (in other words, I do not think "yet another possibility" of waiting for the older versions of gc/prune to die out is a viable solution to the issue Stefan Näwe noticed).

Thanks.