Re: "IMAP IDLE"-like long-polling "git fetch"

From: Eric Wong <e@80x24.org>
Date: May 2, 2019, 08:50 UTC
Message-ID: <20190502085055.34kkll2deowat6il@dcvr>
In-Reply-To: <CAGZ79kb9Tbnxe1mSnxpqT_FO6Gdi6wxd-r2YarHXRF1sVRyxLA@mail.gmail.com>

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.