From: Junio C Hamano <gitster@pobox•com>
To: Jonathan Tan <jonathantanmy@google•com>
Cc: "git\@vger.kernel.org" <git@vger•kernel.org>,
markbt@efaref•net, git@jeffhostetler•com
Subject: Re: Proposal for "fetch-any-blob Git protocol" and server design
Date: Wed, 15 Mar 2017 10:59:03 -0700 [thread overview]
Message-ID: <xmqqinnafml4.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <ffd92ad9-39fe-c76b-178d-6e3d6a425037@google.com> (Jonathan Tan's message of "Tue, 14 Mar 2017 15:57:57 -0700")
Jonathan Tan <jonathantanmy@google•com> writes:
> == Design
>
> A new endpoint "server" is created. The client will send a message in
> the following format:
>
> ----
> fbp-request = PKT-LINE("fetch-blob-pack")
> 1*want
> flush-pkt
> want = PKT-LINE("want" SP obj-id)
> ----
>
> The client may send one or more SHA-1s for which it wants blobs, then
> a flush-pkt.
By "SHA-1s for which it wants blobs", you mean that "want" only
allows one exact blob object name? I think it is necessary to
support that mode of operation as a base case, and it is a good
starting point.
When you know
- you have a "partial" clone that initially asked to contain only
blobs that are smaller than 10MB, and
- you are now trying to do a "git checkout v1.0 -- this/directory"
so that the directory is fully populated
instead of enumerating all the missing blobs from the output of
"ls-tree -r v1.0 this/directory" on separate "want" requests, you
may want to say "I want all the blobs that are not smaller than 10MB
in this tree object $(git rev-parse v1.0:this/directory)".
I am not saying that you should add something like this right away,
but I am wondering how you would extend the proposed system to do
so. Would you add "fetch-size-limited-blob-in-tree-pack" that runs
parallel to "fetch-blob-pack" request? Would you add a new type of
request packet "want-blob-with-expression" for fbp-request, which is
protected by some "protocol capability" exchange?
If the former, how does a client discover if a particular server
already supports the new "fetch-size-limited-blob-in-tree-pack"
request, so that it does not have to send a bunch of "want" request
by enumerating the blobs itself? If the latter, how does a client
discover if a particular server's "fetch-blob-pack" already supports
the new "want-blob-with-expression" request packet?
> === Endpoint support for forward compatibility
>
> This "server" endpoint requires that the first line be understood, but
> will ignore any other lines starting with words that it does not
> understand. This allows new "commands" to be added (distinguished by
> their first lines) and existing commands to be "upgraded" with
> backwards compatibility.
next prev parent reply other threads:[~2017-03-15 17:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-14 22:57 Proposal for "fetch-any-blob Git protocol" and server design Jonathan Tan
2017-03-15 17:59 ` Junio C Hamano [this message]
2017-03-16 17:31 ` Jonathan Tan
2017-03-16 21:17 ` Junio C Hamano
2017-03-16 22:48 ` Jonathan Tan
2017-03-28 23:19 ` Stefan Beller
[not found] ` <00bf01d2aed7$b13492a0$139db7e0$@gmail.com>
2017-04-12 22:02 ` Kevin David
2017-04-13 20:12 ` Jonathan Tan
2017-04-21 16:41 ` Kevin David
2017-04-26 22:51 ` Jonathan Tan
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqinnafml4.fsf@gitster.mtv.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@jeffhostetler$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=jonathantanmy@google$(echo .)com \
--cc=markbt@efaref$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox