From: Jeff King <firstname.lastname@example.org> To: Shawn Pearce <email@example.com> Cc: "Junio C Hamano" <firstname.lastname@example.org>, "Ævar Arnfjörð" <email@example.com>, "Git Mailing List" <firstname.lastname@example.org> Subject: Re: upload-pack is slow with lots of refs Date: Wed, 3 Oct 2012 16:13:16 -0400 [thread overview] Message-ID: <20121003201316.GA4484@sigill.intra.peff.net> (raw) In-Reply-To: <CAJo=hJtZ_8H6+kXPpZcRCbJi3LPuuF7M1U8YsjAp-iWvut9oMw@mail.gmail.com> On Wed, Oct 03, 2012 at 12:41:38PM -0700, Shawn O. Pearce wrote: > > 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. This has the downside of > authentication twice over SSH, which may prompt for a password twice. > But the user can get out of this by setting remote.NAME.uploadpack = > git-upload-pack and thus force the Git client to use the current > protocol if they have a new client and must continue to work over SSH > with an old server, and don't use an ssh-agent. It's a shame that we have to reestablish the TCP or ssh connection to do the retry. The password thing is annoying, but also it just wastes a round-trip. It means we'd probably want to default the v2 probe to off (and let the user turn it on for a specific remote) until v2 is much more common than v1. Otherwise everyone pays the price. It may also be worth designing v2 to handle more graceful capability negotiation so this doesn't come up again. Another alternative would be to tweak git-daemon to allow more graceful fallback. That wouldn't help us now, but it would if we ever wanted a v3. For stock ssh, you could send: sh -c 'git upload-pack2; test $? = 127 && git-upload-pack' which would work if you have an unrestricted shell on the other side. But it would break for a restricted shell or other "fake" ssh environment. It's probably too ugly to have restricted shells recognize that as a magic token (well, I could maybe even live with the ugliness, but it is not strictly backwards compatible). I was hoping we could do something like "git upload-pack --v2", but I'm pretty sure current git-daemon would reject that. > Over HTTP we can request ?service=git-upload-pack2 and retry just like > git:// would, or be a bit smarter and say > ?service=git-upload-pack&v=2, and determine the protocol support of > the remote peer based on the response we get. If we see an immediate > advertisement its still the "v1" protocol, if we get back the "yes I > speak v2" response like git:// would see, we can continue the > conversation from there. Yeah, I would think "&v=2" would be better simply to avoid the round-trip if we fail. It should be safe to turn the new protocol on by default for http, then. -Peff
next prev parent reply other threads:[~2012-10-04 21:50 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-10-03 12:36 Æ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 [this message] 2012-10-04 21:52 ` Sascha Cunz 2012-10-05 0:20 ` Jeff King 2012-10-05 6:24 ` Johannes Sixt 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 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 \ --in-reply-to=20121003201316.GA4484@sigill.intra.peff.net \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: upload-pack is slow with lots of refs' \ /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
Code repositories for project(s) associated with this inbox: https://80x24.org/mirrors/git.git 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).