Revisiting Deprecating `master`

Changing default repo branch names is but a small step toward inclusive language across tech, but is not a replacement for systemic change and recognizing that black lives matter in ALL aspects of our life.

3 years ago I first wrote about the idea of deprecating the use of master. Times have changed and the tools and consensus has changed to reflect that thought. Git recently updated to allow global config changes to use a different default branch name at creation.

GitHub is working towards these goals, and while some changes have been inplemented, they are promising later this year a seamless migration path for existing repositories, which is important for large projects with lots of contributors and forks.

Scott Hanselman has a great overview of how to make branch name changes for local existing repos.

GitHub is My View Source

When I first started learning web development in earnest, (beyond basic HTML), the community college I was attending was still teaching Dreamweaver as de facto method of building a site and using Photoshop and tables based layouts. Meanwhile I had launched my first blog with WordPress, fresh off the 1.5 release that brought full themes, XHTML and CSS. Reading blog posts on the subjects was basically the way I learned those skills. And viewing the page source of the authors writing those posts.

Fast forward to 2016, and I still view source. More often than not now, I’m learning from GitHub repositories. Which is why finding the Octotree browser plugin was such a find. Rather than having to navigate back and forth inside a repo, you get a tree view of the files to the left of the browser window. If you find your self using the back button and navigating breadcrumbs, I highly recommend checking it out.

First Thoughts: Holy Grail of Blogging from iOS with Jekyll

I have been researching and thinking seriously about moving away from database driven blog engines to static file blogging for quite awhile. My extensive research has me convinced for my ideal workflow, Jekyll will be the answer—except for my goal to somewhat easily blog from my phone. All of the front matter could be handled by TextExpander snippets or custom keyboard shortcuts in Drafts or Editorial. The issue has been that with an iOS device, you are basically confined to using Dropbox or iCloud for the text/markdown files. Wanting to keep everything in a Git repo under version control, I hadn’t found a way to automagically push a Dropbox file to a Git repo without having an always on machine at home using some listening app like Hazel to do this. While that isn’t out of the question, I want something straight from the device.

Extensive Googling finally led me to Zappier. Similar to IFTTT, they have a Github/Dropbox workflow that allows you to send a pull request to Github when a new file is added to a directory in Dropbox. And while if I was simply using Github pages to host a Jekyll site, that would be the end to a simple solution.

However, I still want to host my own data on my own VPS (more on that later). Enter Jekyll Hook, which, while not seemingly for the faint of heart, allows one to run their own “Github Pages” on their own server.

So, while all untested at this point, on paper it seems I can have a dedicated Dropbox folder synced with an iOS editor that when a markdown file is saved to it, Zapier will attempt to send a pull request and merge it to a Github hosted repo of my blog [footnote, possibly need to have iOS app to approve pull request but option is in the recipe for the workflow. I assume it will work save for any previous files by same name causing a merge conflict]. From that, the Jekyll Hook script/solution will fire and rebuild the the site, all without leaving the convenience of my iOS device.

Potential magic I tell you.