Per-repo update hooks with gitolite
Posted: Wed, 23 July 2014 | permalink | 3 Comments
Gitolite is a popular way to manage collections of git repositories entirely from the command line – it’s configured using configuration stored in a git repo, which is nicely self-referential. Providing per-branch access control and a wide range of addons, it’s quite a valuable system.
In recent versions (3.6), it added support for configuring per-repository
git hooks from within the
gitolite-admin repo itself – something which previously required directly
jiggering around with the repo metadata on the filesystem. It allows you to
“chain” multiple hooks together, too, which is a nice touch. You can, for
example, define hooks for “validate style guidelines”, “submit patch to code
review” and “push to the CI server”. Then for each repo you can pick which
of those hooks to execute. It’s neat.
There’s one glaring problem, though – you can only use these chained,
per-repo hooks on the
update hook is special, and gitolite wants to make sure you
never, ever forget it. You can hook into the update processing chain by
using something called a “virtual
ref”; they’re stored in a separate
configuration directory, use a different syntax in the config file, and if
you’re trying to learn what they do, you’ll spend a fair bit of time on
them. The documentation describes VREFs as “a mechanism to add additional
constraints to a push”. The association between that and the update hook
is one you get to make for yourself.
The interesting thing is that there’s no need for this gratuitous difference
in configuration methods between the different hooks. I wrote a very small
that makes the
update hook configurable in exactly the same way as the other
server-side hooks, with no loss of existing functionality.
The reason I’m posting it here is that I tried to submit it to the primary gitolite developer, and was told “I’m not touching the update hook […] I’m not discussing this […] take it or leave it”. So instead, I’m publicising this patch for anyone who wants to locally patch their gitolite installation to have a consistent per-repo hook UI. Share and enjoy!
You forgot to comment why the patch was rejected.
Its interesting to know! Thanks
From: Matt Palmer
“I’m not touching the update hook” was the reason given for why the patch was rejected. The reasoning given for not touching the update hook was (paraphrasing) “because it’s special to gitolite”, but why being special to gitolite should make users have to care was never explained.
If you’d like to drop me an e-mail (
email@example.com) I can send you the complete IRC log.
I use gitolite as well and was curious. I thought you just omitted it but its just plain curiosity :)
Post a comment
All comments are held for moderation; markdown formatting accepted.