A few weeks ago, Facebook published a blog post called Sapling: Source control thatās user-friendly and scalable that I read with great interest.
Source control is an interest of mine.
Itās this absolutely critical tool in our software lives, but itās got this ruthless learning curve that leads to most people carving out a small handful of commands they feel confident using, and never straying outside of those.
People keep trying to figure out ways to make it easier to use ā Iām thinking of things like Tower, GitHub Desktop, and Visual Studio Codeās Source Control ā and theyāre actually pretty great.
Iām particularly impressed with the Visual Studio Code one, because it embraces the exact same terminology that you find when using the git
command line interface, but it organizes that information and presents it all in very usable ways (the conflict resolution tooling in particular is night and day better than anything Iāve used before).
Plus, itās always fun to hear about people dealing with devex scaling issues.
Theyāve got so many people over there writing so much code that they have to have huge internal teams to make tools for the rest of them to use just to keep up.
Thatās nuts.
Godspeed to āem.
Enter sapling, their new CLI tool, which seems to be a new client for git repositories.
That is, you can bring your own git repository, but instead of using the git
CLI or any of the graphic clients I mentioned above, you use their alternative CLI, which you invoke on the command line with sl
.
Hereās the thing⦠āsaplingā is a great project name and sl
is a great name for a command.
Thereās only one problem, and itās a showstopper: sl
is taken!
Hereās what I see when I run sl
in my terminal:

Iāll go into why this is very important, and in fact the remainder of this blog post is entirely about how much I love this command and what it means to me, so I apologize if you want to learn more about sapling.
I literally cannot even try it, because I cannot install it, because of this naming collision.
So youāre on your own.
I hope itās great.
Hereās the output of man sl
, which has a lot to unpack:
SL(1) General Commands Manual SL(1)
NAME
sl - cure your bad habit of mistyping
SYNOPSIS
sl [ -alFc ]
DESCRIPTION
sl is a highly advanced animation program for curing your bad habit of
mistyping.
-a An accident is occurring. People cry for help.
-l Little version
-F It flies like the galaxy express 999.
-c C51 appears instead of D51.
SEE ALSO
ls(1)
BUGS
It sometimes lists directory contents.
AUTHOR
Toyoda Masashi (mtoyoda@acm.org)
March 31, 2014 SL(1)
First of all.. letās check out some of these delightful alternate modes.
Hereās the output of sl -a
:

Youāll notice, as promised, that people cry for help.
There are a few other fun flags, but Iāll leave exploring those as an exercise for the reader.
One tip: try combining flags.
Some fun facts about sl
:
- Looking at the source code, it seems this program dates back to 1993, when this blogās author was five years old.
sl
, of course, is short for steam locomotive.
- The author, Masashi Toyoda, is currently a professor at The University of Tokyo, but he still highlights his true claim to fame ā
sl
, of course ā on his homepage
- It takes about six seconds to run
- If you try to kill it by pressing ctrl c to send an interrupt signal, it just ignores you.
This is very annoying in a peevish way that I find charming.
You will sit through the animation.
The man page makes it sound like the motivation for this was to help break a habit of misstyping ls
as sl
.
If, each time you make that mistake, youāre forced to watch a 6 second animation that you cannot skip⦠perhaps that will help you break that habit.
This is kind of like the command line version of Mavala Stop Deterrent Nail Polish Treatment, a product Iāve personally found very helpful.
You may have heard of it.
Itās a clear nail polish you can put on which tastes terrible.
If you find yourself idly biting your nails, it will help you stop.
Itās incredibly helpful as a habit breaker.
I personally do not misstype ls
as sl
very often.
In fact I often will idly type sl
on purpose and watch the train animation when Iām thinking thru a problem.
But I have found it useful to help break some other habits.
Iāll give one more example.
One command line habit I have is running hub browse
to open the current repo on github.com.
Itās great.
Itās context dependent, so for example if youāre currently on a branch, it will open that branch on github.com.
But I want to break this habit.
A few years ago, GitHub introduced an official CLI called gh
.
I installed that too, and itās also pretty good, and in fact it also has a command called gh browse
.
Based on this doc comparing hub
and gh
, I would like to stop using hub
entirely and just use gh
.
Thereās only two problems:
gh browse
does not seem to be as clever as hub browse
; it just loads the repo home page, no matter what branch youāre on
- my damn muscle memory continues to type
hub browse
no matter what I do
So⦠where does sl
come in?
First step: uninstall hub with brew uninstall hub
.
Itās gone now.
Nice.
Now when I type hub browse
, I see this:
$ hub
zsh: command not found: hub
Thatās accurate enough, but itās not sufficiently punitive to be effective.
Second step: bring in the steam locomotive
I added this alias to my shell configuration:
Now, whenever I type hub browse
⦠I get the train.
Third step: make gh browse
context dependent.
Running man gh-browse
, I see that gh browse
actually has some handy-looking options:
OPTIONS
-b, --branch <string>
Select another branch by passing in the branch name
-c, --commit
Open the last commit
(plus some others, not pictured).
Which is to say that you can run gh browse --branch asdf
to open github to branch asdf.
Or you can run gh browse --commit
to browse directly to the last commit, wherever youāre currently checked out.
So, a script like this, built on top of the gh
CLI, kinda-sorta recreates the behavior of hub browse
:
#!/usr/bin/env sh
branch="$(git symbolic-ref --short HEAD 2>/dev/null)"
if [ $? -eq 0 ]; then
gh browse --branch="$branch"
else
gh browse --commit
fi
So, now we can save that file as git-browse
, and put it somewhere on our $PATH
.
Now I can type simply git browse
and git will find that git-browse
script and invoke it.
Under the hood, it uses the gh
command.
And if I ever forget, and type hub browse
, I get to look at a train and contemplate my choices.