back
12 comments
I did this recently as a more generalised service for tracking changes to the output of commands:

https://github.com/ianmiell/alert-on-change/blob/master/READ...

It adds the concept of degree of change to the output triggering an alert.

This looks great. Have you thought about turning it into a unix filter?
Hmmm, good idea.
https://github.com/sickill/git-dude

This one is pretty similar and slightly more readable imo (if shell-scripts can ever be considered readable). Just replace the notify-function with whatever you want to execute instead.

If you're using GitLab.com or GitLab EE it has a project service that sends you an email on every push with the diff of the commits.
Different use case, but I can not recommend using Sibbell[0] enough. Especially when you have more than a handful of dependencies, tracking issues, fixes and their eventual release is crucial.

[0] https://sibbell.com/about/

Stupidly inefficient. `git ls-remote --heads --tags ‹URL›`
That only gives you the commit for the head of the branches. If there were multiple commits since you checked last, you'll miss some!
You will miss some. But then you just make a diff on the commits' SHA and only then you clone the repo (or fetch an archive, which is quicker).

You save a lot of time / bandwidth / space this way.

You only delay saving time and bandwidth — you eventually have to clone the repo for any ops other than checking the head SHAs and unless the repo is rarely updated, the delay will be short.
Use git-archive or curl: gzipped source code is always smaller than a full versioned repo…
You don't need the full versioned repo, just the top commit (ie cloning with depth=1). Also, git compresses the objects before sending them.