SPR, a Worthy Heir to Arcanist – Finally Quenching my Phabricator Nostalgia

2024/05/26

–Phinally something! –Tools for phools –GitHub is the Microsoft of Git. Oh, wait.

Ever since Evan Priestley announced Phabricator’s end of support in 2021, I’ve been keeping an eye open for alternatives1. At the time, GitHub was already pretty entrenched, and since then they seem to have dug in more2.

If you miss the benefits of the arcanist+phabricator workflow, if you’re into similar alternative workflows or just dissatisfied with things like gitflow, it’s usually a tough sell to get a team, let alone a company, to update their processes in deep ways.

Stumbling upon SPR

I recently ran into SPR, a tool that has now existed for a year or two, and which is the first utility I tried that immediately and easily made me enjoy working with GitHub3.

What it solved for me

My main gripes with GitHub, along with the workflows that often accompany projects hosted there4 are these:

Poor Iterative Review Experience

The review UI is not adapted to my amend and rebase-heavy workflow. It sucks for me, and it sucks for my reviewers. I usually work with a single commit per branch that gets amended, and rebase or cherry-pick branches together when I depend on other branches with features that have not reached master/main yet (that’s basically the official epriestley Workflow).

Yes, I could go through the effort of keeping things in separate commits on each of my branches, but that usually implies manual overhead, as it makes it harder to compose different features together when they are still a work in progress.

Simply put, I wish GitHub would have a notion of different versions of a PR to easily let reviewers see what has changed since my last review. That would help everyone involved in a PR’s lifecycle.

Synthetic Commits

That’s where SPR’s main benefit comes in: you do your thing locally, and when it’s time to create or update your PR, SPR will create a synthetic commit that contains the changes that were made since the last update to the branch.

I did nothing special to obtain the list of above commits: the commit titles are taken verbatim from the description I type when I run spr diff to update the PR, and my local branch still has a single commit.

Stacking PRs

The other mildly annoying thing with GitHub, is publishing PRs that depend on another (one way to call this is stacking PRs).

It usually involves manually changing the source branch of a PR after opening it, and to do quite some housekeeping when integrating feedback or merging the branches: the higher the stack, the more annoying it gets.

SPR will ‘stack’ PRs as soon as the parent commit has not landed yet, and makes it easy to update the right PR with the right changes.

Branch Housekeeping

The last annoying thing about most git workflows, is that every dev is left with the task of managing their local branches. Arcanist users know the deep sense of pleasure caused by arc land always getting rid of unneeded branches for them.

Now you can experience this too: SPR gives you the option of simply commiting to master! This works well enough that even my own “one-commit-per-feature-branch” now feels like being needlessly complex to me.

Similarly to arcanist, after spr land is done, your local state is clean and you don’t need to take care to remove any branches5.

Limitations

SPR is awesome. However, its authors are still humans:

But these aren’t really SPR’s fault. It’s awesome, and it’s free as in freedom!

Thank You Cord (!)

I’m extremely grateful for the cord.com folks for having allowed Sven, aka @spacedentist, to build and publish this tool6.

This is simply awesome, and will make each of my days a tiny bit better.

If you’re curious to learn more, head over to SPR’s documentation

  1. I obviously need to mention phorge here, as well as my own earlier and clumsy pseudo-arc for Gitlab. ↩︎

  2. I guess I should also mention GitLab. funnily I have only heard of them very little since I last worked with them. ↩︎

  3. I’ve mentioned Graphite in my earlier post about Phorge. I unfortunately never got to try them out in a real setting, because giving them access to the relevant repositories was a no-no. SPR’s main benefit is definitely that it can be used by individual devs without anyone else’s permission. ↩︎

  4. besides the UI not being snappy enough, but more on that another day… ↩︎

  5. Sadly, spr won’t clean up if you’re not spr land‘ing from a commit on master. But that should be easy to handle with a wrapper script. ↩︎

  6. It seems that Sven has left cord.com ↩︎