From: Johannes Sixt <j.sixt@viscovery.net>
To: Shawn Pearce <spearce@spearce.org>
Cc: "Jeff King" <peff@peff.net>, "Junio C Hamano" <gitster@pobox.com>,
"Ævar Arnfjörð" <avarab@gmail.com>,
"Git Mailing List" <git@vger.kernel.org>
Subject: Re: upload-pack is slow with lots of refs
Date: Fri, 05 Oct 2012 08:24:01 +0200 [thread overview]
Message-ID: <506E7D01.8080509@viscovery.net> (raw)
In-Reply-To: <CAJo=hJtZ_8H6+kXPpZcRCbJi3LPuuF7M1U8YsjAp-iWvut9oMw@mail.gmail.com>
Am 10/3/2012 21:41, schrieb Shawn Pearce:
> On Wed, Oct 3, 2012 at 11:55 AM, Jeff King <peff@peff.net> wrote:
>> On Wed, Oct 03, 2012 at 11:53:35AM -0700, Junio C Hamano wrote:
>>> Jeff King <peff@peff.net> writes:
>>>
>>>>> Has there been any work on extending the protocol so that the client
>>>>> tells the server what refs it's interested in?
>>>>
>>>> I don't think so. It would be hard to do in a backwards-compatible way,
>>>> because the advertisement is the first thing the server says, before it
>>>> has negotiated any capabilities with the client at all.
>>>
>>> That is being discussed but hasn't surfaced on the list.
>>
>> Out of curiosity, how are you thinking about triggering such a new
>> behavior in a backwards-compatible way? Invoke git-upload-pack2, and
>> fall back to reconnecting to start git-upload-pack if it fails?
>
> Basically, yes. New clients connect for git-upload-pack2. Over git://
> the remote peer will just close the TCP socket with no messages. The
> client can fallback to git-upload-pack and try again. Over SSH a
> similar thing will happen in the sense there is no data output from
> the remote side, so the client can try again.
These connections are bidirectional. Upload-pack can just start
advertising refs in the "v1" way and announce a "v2" capability and listen
for response in parallel. A v2 capable client can start sending "wants" or
some other signal as soon as it sees the "v2" capability. Upload-pack,
which was listening for responses in parallel, can interrupt its
advertisements and continue with v2 protocol from here.
This sounds so simple (not the implementation, of course) - I must be
missing something.
-- Hannes
next prev parent reply other threads:[~2012-10-05 6:43 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-03 12:36 upload-pack is slow with lots of refs Ævar Arnfjörð Bjarmason
2012-10-03 13:06 ` Nguyen Thai Ngoc Duy
2012-10-03 18:03 ` Jeff King
2012-10-03 18:53 ` Junio C Hamano
2012-10-03 18:55 ` Jeff King
2012-10-03 19:41 ` Shawn Pearce
2012-10-03 20:13 ` Jeff King
2012-10-04 21:52 ` Sascha Cunz
2012-10-05 0:20 ` Jeff King
2012-10-05 6:24 ` Johannes Sixt [this message]
2012-10-05 16:57 ` Shawn Pearce
2012-10-08 15:05 ` Johannes Sixt
2012-10-09 6:46 ` Shawn Pearce
2012-10-09 20:30 ` Johannes Sixt
2012-10-09 20:46 ` Johannes Sixt
2012-10-03 20:16 ` Ævar Arnfjörð Bjarmason
2012-10-03 21:20 ` Jeff King
2012-10-03 22:15 ` Ævar Arnfjörð Bjarmason
2012-10-03 23:15 ` Jeff King
2012-10-03 23:54 ` Ævar Arnfjörð Bjarmason
2012-10-04 7:56 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King
2012-10-04 7:58 ` [PATCH 1/4] peel_ref: use faster deref_tag_noverify Jeff King
2012-10-04 18:24 ` Junio C Hamano
2012-10-04 8:00 ` [PATCH 2/4] peel_ref: do not return a null sha1 Jeff King
2012-10-04 18:32 ` Junio C Hamano
2012-10-04 8:02 ` [PATCH 3/4] peel_ref: check object type before loading Jeff King
2012-10-04 19:06 ` Junio C Hamano
2012-10-04 19:41 ` Jeff King
2012-10-04 20:41 ` Junio C Hamano
2012-10-04 21:59 ` Jeff King
2012-10-04 8:03 ` [PATCH 4/4] upload-pack: use peel_ref for ref advertisements Jeff King
2012-10-04 8:04 ` [PATCH 0/4] optimizing upload-pack ref peeling Jeff King
2012-10-04 9:01 ` Ævar Arnfjörð Bjarmason
2012-10-04 12:14 ` Nazri Ramliy
2012-10-03 22:32 ` upload-pack is slow with lots of refs Ævar Arnfjörð Bjarmason
2012-10-03 23:21 ` Jeff King
2012-10-03 23:47 ` Ævar Arnfjörð Bjarmason
2012-10-03 19:13 ` Junio C Hamano
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=506E7D01.8080509@viscovery.net \
--to=j.sixt@viscovery.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=peff@peff.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.