> On 2019/05/06, at 12:46, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > > Hi, > > Jonathan Tan wrote: >> Matthew DeVore wrote: > >>> I'm considering implementing a feature in the Git protocol which would >>> enable efficient and accurate object negotiation when the client is a >>> partial clone. I'd like to refine and get some validation of my >>> approach before I start to write any code, so I've written a proposal >>> for anyone interested to review. Your comments would be appreciated. >> >> Thanks. Let me try to summarize: The issue is that, during a fetch, >> normally the client can say "have" to inform the server that it has a >> commit and all its referenced objects (barring shallow lines), but we >> can't do the same if the client is a partial clone (because having a >> commit doesn't necessarily mean that we have all referenced objects). > > Ah, interesting. When this was discussed before, the proposal has been > that the client can say "have" anyway. They don't have the commit and > all referenced objects, but they have the commit and a *promise* that > they can obtain all referenced objects, which is almost as good. > That's what "git fetch" currently implements. Doesn’t that mean the “have” may indicate that the client has the entire repository already, even though it’s only a partial clone? If so, then the client intends to ask for some tree plus trees and blobs 2-3 levels down deeper, how would the server distinguish between those objects the client *really* has and those that were just promised to them? Because the whole purpose of this hypothetical request is to get a bunch of promises fulfilled of which 0-99% are fulfilled already. > > For blob filters, if I ignore the capability advertisements (there's > an optimization that hasn't yet been implemented to allow > single-round-trip fetches), the current behavior takes the same number > of round trips as this proposal. Where the current approach has been > lacking is in delta base selection during fetch-on-demand. Ideas for > improving that? Maybe something like this (conceptually based on original proposal) ? 1. Client sends request for an object or objects with an extra flag which means “I can’t really tell you what I already have since it’s a chaotic subset of the object database of the repo” 2. Server responds back with set of objects, represented by deltas if that is how the server has them on disk, along with a list of object-IDs needed in order to resolve the content of all the objects. These object-IDs can go several layers of deltas back, and they go back as far as it takes to get to an object stored in its entirety by the server. 3. Client responds back with another request (this time the extra flag sent from step 1 is not necessary) which has “want”s for every object the server named which the client already has. Very hand-wavey, but I think you see my idea.
