Re: Monitoring a repository for changes

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Jun 21, 2017, 21:19 UTC
Message-ID: <20170621211908.GF60603@aiede.mtv.corp.google.com>
In-Reply-To: <CAKuVd4Bdhreu6wrwDp1Bia56Db=TXYMQcitsznaRM+QcYVzJnQ@mail.gmail.com>

Hi,

Tim Hutt wrote:

Show 12 quoted lines

> Currently if you want to monitor a repository for changes there are
> three options:
>
> * Polling - run a script to check for updates every 60 seconds.
> * Server side hooks
> * Web hooks (on Github, Bitbucket etc.)
>
> Unfortunately for many (most?) cases server-side hooks and web hooks
> are not suitable. They require you to both have admin access to the
> repo and have a public server available to push updates to. That is a
> huge faff when all I want to do is run some local code when a repo is
> updated (e.g. play a sound).

On the polling side, it is possible to improve things a little: https://www.kernel.org/mirroring-kernelorg-repositories.html https://github.com/mricon/grokmirror

A hanging GET or websocket is more client-friendly but more expensive server-side. That doesn't rule out making it happen on some servers if someone does the work. If I understand correctly then this architecture tends to lead to centralization --- a small number of services providing notifications pushed from multiple sources, as with https://developers.google.com/web/fundamentals/engage-and-retain/push-notifications/how-push-works

If someone wants to try adding something like grokmirror (which describes the state of multiple repositories, amortizing the per-request costs) to git, especially if it supports something etag-like as Jeff King suggested, then I would be interested.

Thanks and hope that helps, Jonathan