Re: Monitoring a repository for changes

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Wed, Jun 21 2017, Tim Hutt jotted:

> Hi,
>
> 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).
>
> Currently people resort to polling
> (https://stackoverflow.com/a/5199111/265521) which is just ugly. I
> would like to propose that there should be a forth option that uses a
> persistent connection to monitor the repo. It would be used something
> like this:
>
>     git watch https://github.com/git/git.git
>
> or
>
>     git watch git@github.com:git/git.git
>
> It would then print simple messages to stdout. The complexity of what
> it prints is up for debate, - it could be something as simple as
> "PUSH\n", or it could include more information, e.g. JSON-encoded
> information about the commits. I'd be happy with just "PUSH\n" though.

Insofar as this could be implemented in some standard way in Git it's
likely to have a large overlap with the "protocol v2" that keeps coming
up here on-list. You might want to search for past threads discussing
that.

> In terms of implementation, the HTTP transport could use Server-Sent
> Events, and the SSH transport can pretty much do whatever so that
> should be easy.

In case you didn't know, any of the non-trivially sized git hosting
providers (e.g. github, gitlab) provide you access over ssh, but you
can't just run any arbitrary command, it's a tiny set of whitelisted
commands. See the "git-shell" manual page (github doesn't use that exact
software, but something similar).

But overall, it would be nice to have some rationale for this approach
other than that you think polling is ugly. There's a lot of advantages
to polling for something you don't need near-instantly, e.g. imagine how
many active connections a site like GitHub would need to handle if
something like this became widely used, that's in a lot of ways harder
to scale and load balance than just having clients that poll something
that's trivially cached as static content.