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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

>> 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.