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.

There are probably children out there holding down spacebar to stay warm in the winter! YOUR UPDATE MURDERS CHILDREN.

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.

movie poster: WRONG
on the left: my website

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:

via @MGoShoe

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 ''
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

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.

1. my even older deployment workflow involved zipping the output folder so I could more easily upload it to the remote hosting server and then copying it over the prior files. It was a huge pain but I made the move to GitHub hosting back in July.