---
I mentioned in yesterday's phlog post that I am now using git to version-control my gopherhole. My main reason for doing so is to help with automated tasks, such as unified deployment of content and maintaining automated changelogs. I've used git professionally for a while, but rarely have I had occasion to dive into some of its more advanced features. I had just such an opportunity now.
I use Gophernicus on FreeBSD to serve the gopherhole. I began by naively using 'git init' to create a local repo in the live directory from which the hole is served, then cloning the repo to my Fedora laptop. When I tried to push changes back to the BSD repo, I ran into an error: "refusing to update checked out branch". The repo I had created on the BSD machine was a non-bare repo, and the files present on disk were considered by git to be checked out of the master branch. As a result, I couldn't push to the repo by default. Already I was in new territory--I had never dealt directly with bare vs. non-bare repos before.
I resolved the issue by creating a bare repo in my home directory on the BSD machine. I then cloned the repo into the live Gophernicus directory. This not only allowed me to clone the repo to my Fedora machine and push changes back, but it allowed me to keep the central repo out of the love Gophernicus directory.
This scheme, however, led to a new problem. Every time I pushed changes back to the bare repo, I would have to log onto the BSD machine and manually pull the changes into the live directory. That was hardly the automated solution I was looking for. This is where I learned about git hooks. Git hooks are fantastic little tools that run scripts when certain actions are performed in git. For example, the post-commit hook can be used to clean up working files in an ignored directory after making a commit. Because they are full scripts, there's no limit to what one can set them to do.
In this case, the git hook I wanted was the post-update hook in the bare repo. Upon the successful completion of a 'git push' from my Fedora machine, the post-update hook changes to the Gophernicus-served repo, pulls the changes into that repo, and updates the changelog with the most recent commits.
Under this system, the Gophernicus-served repo is never modified directly by a user. When I want to update the gopherhole, I clone the bare repo to my current machine, make my changes, commit them, and push them back to the bare repo. Everything else is taken care of by git itself.
Although generally dislike it when tons of features are crammed into a single application, I often enjoy finding out that a utility I'm already using has even more powerful functionality than I realized. Git is certainly going to be a useful tool for me and for the gopherhole going forward.
---
[Last updated: 2021-10-28]