(Image linked from https://themes.gohugo.io/theme/hugo-now/)
Well, it has been one day since I finished the installation of Hugo as my blogging back-end. Wow. It was a bit of a mess. I need to first say that now that everything is up and running, I really like it. Once set up, it makes a lot of sense in the way they have chosen to do things. However, it was a bear to get my head around the setup. Jekyll was easy to get set up. Github is set up with Jekyll in mind, and that does make a difference. The way that Github is set up for static pages does not play as friendly with Hugo. The difference seems to lie in whether you used your “name.github.io” url or if you set up a new repo and then use that repo to launch your site. Depending on how you set up your Github makes a big difference on how you should deploy your site. Because I had just deployed Jekyll in the past, I was used to the way they do it. You make your name.github.io repo, you import your local Jekyll repo and Badabing, you are done. Hugo? Not so much. Hugo outlines ways to host, but it doesn’t do a very good job of telling you not to use your “name.github.io” repository for hosting. It does talk about hosting from a docs folder, but it only links to a github page telling you that if you are going to use the docs folder that you cannot use your “name.github.io” repo. I’m not saying the information is not there. I’m just saying it isn’t super explicit and does expect a certain level of background knowledge or understanding of all of the terminology that they are using in the instructions. So here is what I had to do to get Hugo working.
Firstly, install Hugo. This step was super easy because it was in the Solus repo. I simply opened up the software center, searched for Hugo, installed and was good to go. I followed the quick start guide on the Hugo website, which was excellently simple.
The problems come with how Github hosts their static pages. If you want a static site, it need to live in the root of the repository, if it is a “name.github.io” account. (I did not realise until after the fact that I should have just used a different repo than the “name.github.io” account in order to get things working more simply.) Which is what I was using. However, Hugo does not put the static site in the root. It puts the static site, by default, in a folder named “public”. So, the solution? Submodules. I had never ever even heard of submodules before, but they are cool. I learned about them while watching a video on how to install Hugo. (I knew I was doing something wrong because the info on that video didn’t exactly suit my situation exactly.) They basically let you host a repo inside of your repo. So, I made a repo named “hugo”. I then hosted my local hugo directory inside of the “hugo” repo. I then created a submodule for my “public” folder that lives in my “name.github.io” repo. That way, my static site is in the root of my “name.github.io” repo. So, when I go to sync, I sync my local hugo folder to my hugo repo and my public folder to the “name.github.io” folder. Nifty.
There was also an issue of themes. I performed the same incantation over the themes directory, pointing a submodule to the themes folder what houses the clone of the git repo that holds the theme I liked. Very, very, cool.
As cool as this is, it took me most of a morning to figure all of this out. I had never worked with submodules before. I didn’t know they were even a thing. None of the Hugo documentation suggests doing anything even remotely similar to this procedure. I also have yet to see if Visual Studio Code will commit to both my main repo and my submodules. We will see.