From: Matthew DeVore <firstname.lastname@example.org>
To: Jonathan Nieder <email@example.com>
Cc: Jonathan Tan <firstname.lastname@example.org>,
Subject: Re: Proposal: object negotiation for partial clones
Date: Mon, 6 May 2019 16:20:19 -0700 [thread overview]
Message-ID: <EA2BD2A8-2641-4B71-8439-66994DE9589F@comcast.net> (raw)
> On 2019/05/06, at 12:46, Jonathan Nieder <email@example.com> wrote:
> 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.
next prev parent reply other threads:[~2019-05-06 23:28 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-28 15:55 Proposal: object negotiation for partial clones Matthew DeVore
2019-05-06 18:25 ` Jonathan Nieder
2019-05-06 19:28 ` Jonathan Tan
2019-05-06 19:46 ` Jonathan Nieder
2019-05-06 23:20 ` Matthew DeVore [this message]
2019-05-07 0:02 ` Jonathan Nieder
2019-05-06 22:47 ` Matthew DeVore
2019-05-07 18:34 ` Jonathan Tan
2019-05-07 21:57 ` Matthew DeVore
2019-05-09 18:00 ` Jonathan Tan
2019-05-14 0:09 ` Matthew DeVore
2019-05-14 0:16 ` Jonathan Nieder
2019-05-16 18:56 ` [RFC PATCH 0/3] implement composite filters Matthew DeVore
2019-05-16 18:56 ` [RFC PATCH 1/3] list-objects-filter: refactor into a context struct Matthew DeVore
2019-05-16 18:56 ` [RFC PATCH 2/3] list-objects-filter-options: error is localizeable Matthew DeVore
2019-05-16 18:56 ` [RFC PATCH 3/3] list-objects-filter: implement composite filters Matthew DeVore
2019-05-17 3:25 ` Junio C Hamano
2019-05-17 13:17 ` Matthew DeVore
2019-05-19 1:12 ` Junio C Hamano
2019-05-20 18:24 ` Matthew DeVore
2019-05-20 18:28 ` Matthew DeVore
2019-05-16 22:41 ` [RFC PATCH 0/3] " Jonathan Tan
2019-05-17 0:01 ` Matthew DeVore
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).