Dustin Boston is a Sr. Software Engineer at SheKnows and lives in Scottsdale, AZ. Thinker of things, typer of words, cooker of food. Burgeoning fashionista.

Packaging up jekyll-do and pushing it out to the world!


I can’t believe Apple won’t let you play MP3 files on your iPhone without importing them through iTunes


JekyllDo now supports workflows!


The Git PR-commit message

I’ve made life easier for myself, and maybe my coworkers, by writing commit messages in a way that works for pull requests on GitHub.

By on in posts

Over the past couple of years I’ve found myself writing commit messages that are intended to be used as both a commit message and a PR (pull request). This is mostly because GitHub will use the commit message from the first commit in a PR as the PR text.

This has changed my overall approach to commit messages in a way that seemed worth documenting. Specifically, I have merged tips for a better commit message with writing a great pull request, and how to write a commit message, so everything those posts mention are still valid.

Here’s a commit message that has been modified to include PR-specific information:

Redirect user to the requested page after login

Users were being redirected to the home page after login, which is less
useful than redirecting to the page they had originally requested before
being redirected to the login form.

* Store requested path in a session variable
* Redirect to the stored location after successfully logging in the user


Visit a page that isn't the homepage, then click login. After logging
in you should be redirected to the page you started on.


This uses the new login process because it's more stable than the
old process (which is slated for retirement).

Resolves: https://trello.com/path/to/relevant/card

As you may have noticed, I now use Markdown in my commit messages. I do this so that GitHub will render the PR nicely without any additional work on my part1.


There are a few benefits of using the hybrid PR-commit approach:

  • It’s DRY: there is only one source for the PR, and it is forever a part of the timeline because it’s in a commit message. Even if you move away from GitHub, you will still have a log of all your PRs.
  • It’s efficient: because of the way that GitHub reads in the PR from your commit message, you don’t have to type it out multiple times.
  • It’s pretty: since GitHub formats PRs with Markdown, you don’t have to make any modifications to the PR. It will look great right away without changing anything.

  1. ProTip: avoid using # for headings, as Git will interpret them as comments and remove them from the commit text. 

Not enough disk space on boot

Ubuntu never has enough free disk space on `/boot`, and when it doesn’t have enough free disk space it won’t update. This is the crazy command I run to fix it.

By on in posts

Ever been greeted with this friendly error while attempting to apply regular old everyday updates to Ubuntu?

Not enough free disk space

The upgrade has aborted. The upgrade needs a total of 25.7 M free space on disk ’/boot’. Please free at least an additional 25.7 M of disk space on ’/boot’. Empty your trash and remove temporary packages of former installations using ‘sudo apt-get clean’.

Yeah. This shit happens to me all the time. You’d think it would be a solved problem and that a solution would be widely available, if not built in. But it’s not, so here’s how I fix it, via Ask Ubuntu:

dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge