Problems

The Set-Up

This past weekend, I updated the blog for the first time in a while. I do web development now at work, and while I'm still inexperienced, it was pretty jarring to return to my site and see how inefficiently I had set up the workflow for updating it.

My old workflow involved two separate repositories: one for the content, plug-ins, configuration files for building the site (I use Pelican), and a separate repository for the deployed site. This seemed suboptimal because it meant that I had to maintain two separate repositories and when I wanted to deploy, I had to copy the output folder from one to the other. I really wanted to use the git subtree push command like I do in the office^[1].

I thought that this was going to be a short, straight-forward operation: delete the old deployment repository, add a gh-pages branch to my old content repo, then the magic command: git subtree push --prefix output origin gh-pages.

I thought wrong.

Anyway, I did end up getting this all to work but it took about three hours.

A Parallel

At the same time, I was watching the first half of the Michigan-Northwestern football game. Both teams were playing very poorly and because the scored stayed 0-0 for so long, it became known as the 'M00N' game on twitter:

When the game finally ended with Trevor Simian, Northwestern's quarterback, falling over on a 2-pt conversion to lose the game, I noticed some remarkable parallels with my current website task: everything was terrible the whole time but eventually the 'good guys' (Me, Michigan) won. I thought about extending this metaphor further but by the time I started this post, I really didn't want to relive any of the game again.

The real reason I wanted to write after undergoing this 'ordeal' was so that I wouldn't forget how to do all these steps again and maybe help someone else out with similar issues.

5 Things I Learned Last Saturday

1. User pages serve out of master branch

I thought all GitHub repositories served off of the gh-pages branch. This is not true.

2. There are multiple ways to deal with unruly subtree pushes

If everything is going well, the 'standard' git subtree push --prefix output origin master command works fine. But sometimes you'll see this:

error: failed to push some refs to 'git@github.com:drewbo/drewbo.com.git'
hint: Updates were rejected because a pushed branch tip is behind its remote
hint: counterpart. Check out this branch and integrate the remote changes
hint: (e.g. 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details

You might not have the "served" branch on your local machine so it's not as simple as just doing git pull. My three solutions, in order of how I try them:

1. Magic Command

   git push origin `git subtree split --prefix build_folder master`:gh-pages --force

   I don't totally understand this but sometimes it works (h/t some blog)

2. Pull Request

   Do the subtree push to a temporary branch and then merge that to master/gh-pages (whatever branch hosts your output files).

3. Delete gh-pages/master (remote and locally)

   Then rebuild and push.

3. DNS changes take time to propagate. Chill

• Any time you make DNS changes with your domain name, just wait a bit.
• Maybe use the DNS Lookup Utility if you're impatient
• Don't screw up your email

4. Git submodules are confusing the first time you try them

Especially when you put submodules in submodules. This article was a big help.

5. Always check .gitignore

I was ignoring the output folder in .gitignore which I seem to do pretty often. This was a boilerplate .gitignore from another project and many times you don't want to commit the output but if you're going to do the subtree push, you need it.