As this site is built using a Static Site Generator, any changes I make to it [such as writing new drivel] requires re-uploading the site to my server [or at least those bits of it which have changed]. I’ve mentioned in a previous post that I use Git for this process: firstly by pushing the 'new stuff' from my laptop up to a central repo, then by logging into my web server and pulling those changed files to the live site.

Although there’s a bit of setting up involved, it actually sounds a lot more complicated than it is –as I hope to demonstrate in this post. And, once setup, it’s a lot quicker method for updating the site than you might imagine --especially if you use a database-driven blog engine like WordPress or Tumblr and think live online editing is the most efficient way to blog.

Another incentive for this post is that, on the Hugo discussion forums, I quite often see folks outlining the workflows they use to keep their Hugo blogs updated [often involving clever scripting and/or chron jobs] and, whilst I can appreciate the ingenuity displayed, I find myself thinking "Why complicate matters so much, when you can achieve the same result, using a couple of simple Git commands?"

So, before I plunge into the details, stopwatches at the ready and we’ll see how long it takes to get this post [wot I am currently writing] from this laptop to live on the web:

Well, there you have it. Less than a minute from laptop to internet sensation. Not bad, eh? And, even more impressive when you think that, into the bargain, I’ve got a complete copy of the site saved locally and also a backup saved to a Git repo, complete with the entire history of site changes.

Suddenly your "New Post" form in WordPress ain’t looking so clever, is it?

I’m actually a bit disappointed that the time wasn’t even faster. I reckon in day-to-day use, it usually takes nearer 30 seconds to go from laptop to web. That’s mainly owing to my network connection usually being a bit perkier, and my usually availing of shell autocomplete to speed up entering the commands [I thought that might be a bit of a cheat if I did it in this video, so I typed 'em all by hand].

One time saving bijou cheat-ette I do use in the video is that I have alias madraserver="ssh -v -pXXXXX name@XXX.XXX.XXX.XXX" saved in my shell profile. So I can just use madraserver to connect, rather than having to remember the syntax of that command.

The other wee bit of prior preparation you need to do, if you want to use Git to manage your Hugo site like this, is to avail of sparsecheckout.

By default, doing a git pull origin master from my webserver will download everything in my Git repo. ie. all my development files, theme files, etc. I don’t need any of this stuff, on the website –just the static webpages themselves. So I only want to pull the files in the public directory [which is where Hugo builds the actual site content]

First of all, I make sure that my web server is configured to serve my site from the public subdirectory of the domain’s directory on my server [I’m serving with Nginx, adapt as necessary if you’re an Apache guy or gal]:

server {
        listen 80;
        listen [::]:80;
        server_name stiobhart.net;
        root /var/www/stiobhart.net/public;
        index index.html;

        ....

    }

Then I need to tell Git to only download the public directory from the repo whenever I issue a git pull origin master command from within /var/www/stiobhart.net. This is where the sparsecheckout comes in:

cd <repo root directory> #ie. /var/www/stiobhart.net, in my case
git config core.sparsecheckout true
echo public/ >> .git/info/sparse-checkout

And there you have it. From now on, any time I issue a git pull... command in that directory, Git will just pull anything new in the public subdirectory, rather than downloading all that extra baggage.

Pretty simples, eh? As the title says, "Why complicate things?"