user/dev discussion of public-inbox itself
 help / color / mirror / code / Atom feed
From: Eric Wong <e@80x24.org>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Stefan Beller <stefanbeller@gmail.com>,
	git@vger.kernel.org, meta@public-inbox.org
Subject: Re: "IMAP IDLE"-like long-polling "git fetch"
Date: Thu, 2 May 2019 09:42:55 +0000	[thread overview]
Message-ID: <20190502094255.kbpzffokvdch63qg@dcvr> (raw)
In-Reply-To: <87ftpxqkji.fsf@evledraar.gmail.com>

Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> 
> On Thu, May 02 2019, Eric Wong wrote:
> 
> > Stefan Beller <sbeller@google.com> wrote:
> >> IIRC, More than half the bandwidth of Googles git servers are used
> >> for ls-remote calls (i.e. polling a lot of repos, most of them did *not*
> >> change, by build bots which are really eager to try again after a minute).
> >
> > Thinking back at that statement; I think polling can be
> > optimized in git, at least.
> >
> > IIRC, your repos have lots of refs; right?
> > (which is why it's a bandwidth problem)
> >
> > Since info/refs is a static file (hopefully updated by a
> > post-update hook), the smart client can make an HTTP request
> > to check If-Modified-Since: to avoid the big response.
> >
> > The client would need to cache the mtime of the last requested
> > refs file; somewhere.
> >
> > IOW, do refs negotiation the "dumb" way; since it's no better
> > than the smart way, really.  Keep doing object transfers the
> > smart way.
> >
> > During the initial clone, smart servers could probably
> > have a header informing clients that their info/refs
> > is up-to-date and clients can do dumb refs negotiation.
> 
> Doing this with If-Modified-Since sounds like an easier drop-in
> replacement (just needs a client change), but I wonder if ETag isn't a
> better fit for this.

ETags overall could work.

> I.e. we'd document some convention where the ETag is a hash of the refs
> the client expects to be advertised in some format, it then sends that
> to the server.

But I was hoping to avoid the overhead of spawning git-http-backend
entirely.  And there's no consistent way to configure ETags on
different static servers.

> That allows the same thing without anyone keeping more state than they
> keep now in their local ref store

I think caching the remote info/refs is useful anyways in case
the user changes their fetch refspec, and it could speed up
invocations of "git ls-remote".

> On the fancier side I think bloom filters are something that's been
> discussed (and I believe someone (Twitter?) had such an internal patch),
> i.e. the client sends a bloom filter of refs they have, and the server
> advertises things they don't know about yet (and due to how bloom
> filters work, some things they *do* know about already but tripped up
> the bloom filter...).

I'm not smart enough to understand such fancy things :)

      reply	other threads:[~2019-05-02  9:42 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-29  3:43 [PATCH] TODO: add note for "IMAP IDLE"-like long-polling "git fetch" Eric Wong
2018-12-29  3:56 ` Eric Wong
2018-12-29  4:38   ` Konstantin Ryabitsev
2018-12-29  6:13     ` Eric Wong
2019-01-09 22:27     ` Stefan Beller
2019-01-09 22:49       ` Konstantin Ryabitsev
2019-05-02  8:50       ` Eric Wong
2019-05-02  9:21         ` Ævar Arnfjörð Bjarmason
2019-05-02  9:42           ` Eric Wong [this message]

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://public-inbox.org/README

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190502094255.kbpzffokvdch63qg@dcvr \
    --to=e@80x24.org \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=meta@public-inbox.org \
    --cc=stefanbeller@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/public-inbox.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).