On Tue, Nov 19, 2024 at 09:16:50AM +0900, Junio C Hamano wrote: > Peijian Ju <eric.peijian@xxxxxxxxx> writes: > > - Based on Mr. Patrick Steinhardt’s comment at [1], since > > remote-object-info operates only on protocol v2, adding a quarantine > > mechanism may lead to differing client-side behavior depending on the > > protocol, which could complicate the feature’s consistency. > > Not doing quarantine would give even _more_ different client-side > behaviour, though. When talking with a server with v2, you'll not > see a cruft object left locally, but with older servers, you'll see > crufts left behind. After a failed remote-object-info call, you can > do an object-info to figure out what you needed to learn about the > object, but only after the failed remote-object-info was against an > older server. > > So, I do not see it as a reason against putting temporary objects > into quarantine. I agree, and that's also what I wanted to say in the linked comment. > Not that I consider it important to give the same client-side > behaviour when talking with older and newer servers, though. It is > natural for a new feature to be available only with versions of Git > that supports the feature, after all. I think having subtly different behaviour like this is a recipe for confusion. As an end user (or rather end developer in this context) it is quite likely that you start to rely on the object either being fetched or not fetched as they probably won't end up testing against servers with both protocol versions. So you'd have to be aware of the fallback behaviour, and given that it is rather subtle and thus easy to miss the end result would likely be confusion when it works different in some repos than in others. > And if we throw that away as a goal, it starts to make more sense > not to add "fetch and locally inspect" anywhere. While having a quarantine directory would help with the case where you have differing end user behaviour depending on the protocol, it of course wouldn't help with the implied performance hit when using the fallback logic. So maybe not having the fallback is the best solution after all, and when users have a good use case for why they need it we could implement it in a future iteration. Patrick
