Stacked Diffs and Valorant
Beautiful (when it works...)
Stacked diffs are often cited as a notable missing workflow of git and Github. The idea is relatively simple in that you are creating an impromptu dev branch and reviewing the changes before eventually pulling that dev branch into your repository.
The reason that they are a core feature I wanted to build into nugit is because of how startup culture works. In startups, pretty much everyone is a developer. Your manager is a developer, your marketer is a developer, your CTO is a developer. Everyone is focused on making things happen and building out the functionality of a new system. That means everyone is focused on building.
Reviewing becomes secondary and is a huge context switch cost. The more time spent reviewing means the more time spent not building. But if you don’t review properly you can break production and everyone will hate their lives.
Stacked diffs are effectively a way of just organizing your features as you build them so you don’t have to wait for the reviews before you continue building on top of features you need to create. If there’s changes you need to make early in the stack, you can easily propagate those changes to the downstream branches. This more or less already handled in Github from a coder perspective. The issue is as a reviewer.
A Brief Aside
With respect to video games, I think of stacked diffs as timing a play as a lurker in a tactical shooter like Valorant. Lurkers need to be able to move in parallel with the team, but at their own pace. They have a different set of context and want to move as fast as possible but lurkers heavily rely on your team matching your pace. The key idea is that lurkers are amazing to work with when they’re good at it, but they’re terrible to work with when they’re bad at it. If they go to slow, you just get caught and are ineffective because not enough noise was created to distract for you. If they move to fast, then the round is effectively over before you can make an impact.
The issue with the current workflow for PRs is that the team is moving really fast but no one is matching each others pace so being effective just ends up being extremely painful. It’s impossible to move at the right speed, which makes plays like this impossibly difficult to manifest (for a software team).
Effective lurking feels criminal
How it works in nugit
When building it into nugit, I decided to manifest stack diffs through stacking PRs to take advantage of a Github user’s familiarity with the idea where you can make a PR and have the base be anything, including the default branch.
When you’re reviewing a stack in Github, for a stack of 3 PRs, you have to either have 3 tabs open or navigate in and out of PRs over and over to get context on whats happening. You get the bare minimum context from the Github PR review screen as it is, and this just drastically cranks up the pain. If each PR was isolated it would be fine, but when you’re two PRs deep on your stack and the last PR draws from both the previous PRs in different files, you’ll be hard pressed to easily understand the changes without significant mental overhead.
Stack of PRs are open on the left with file exploration on the right
I added a stack view specifically to cover this situation. You can easily thumb between PRs to be able to see what files are changed between the two while looking at the directory. This gets me 80% of what I want when I first look at a stack. I just want to know what the differences between PRs are in terms of the files they’re effecting, because I already know the code base and can pick out if theres files missing that need to be changed to roll out a described feature.
If you want to try nugit, you can find it here.