Jeff King <p...@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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
