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.

We don’t have to discuss the sub 90% uptime

The existing GitHub UI for PRs has largely been unchanged for well over a decade. It works, it’s familiar to people, it’s inoffensive. But it’s just not enough anymore.

Picture a typical week on a fast-moving software startup team—the sort people would call “scrappy.” You’re clocking in Monday morning and building out a feature corresponding to a ticket, test it, and set up the PR by lunch. You ping your manager to review it and they say they’ll review it ASAP. Cool. Time to start the next ticket which involves building a new feature on top of what you built this morning. You knock it out before you clock out for the day and you ping your manager again. They’ll review it ASAP. Fast forward to tomorrow and by end of day you’ve knocked out another two features, each feature extending from the previous.

It’s now the middle of the week and your manager can finally look at your PRs. They find an issue with a function you wrote in the first PR. They message you on slack saying they want the inputs and outputs changed slightly. But PRs 2-4 that you wrote all rely on this function.

Another message comes in and they say “oh also there’s merge conflicts.” Someone else got their PR in before you. Maybe they changed some of the same files? Worse they changed the same functions. And now you have to resolve conflicts for your entire PR stack. You’ve gone from finishing 4 tickets before Wednesday to getting nearly nothing done.

It’s a table flipping moment. Why couldn’t your manager just review faster?

Turns out the manager has been neck deep in PRs from the rest of your team and they’re just barely staying afloat. One of your teammates is a new engineer fresh from college. They don’t even separate different features to different PRs yet. They’re all combined in one. It’s a 4000 line diff. Time your manager spends reviewing code now directly correlates with dissatisfaction with their job and a desire to leave the role.

No one wins in this situation. I’m also not making a novel observation.

Graphite is attempting to solve these issues, but they are no longer opensource. GH Stack is open source but it breaks the usage of the Github UI so utilizing the tool requires a commitment of the whole team.

To fill the void and solve my annoyances, I made something called nugit that builds on top of Github with the goal of integrating seamlessly with existing workflows, so I can benefit from using it on projects I care about. Its open source so anyone can fork it (I won’t be accepting external PRs). Follow its development and my shilling of it here.

I was vibe-coding a CI/CD implementation and ran into an issue. My GitHub Runner had run out of memory while installing some packages. So naturally, I copied the logs into the chat window and immediately the build file has some new lines written that look suspiciously like malware. “free-disk-space” is the name of the action. Its like something out of the early 2010s. But it isn’t malware. In fact, its used in by over 16 thousand people in their repositories to solve the same issue I had with wanting to customize a GitHub Runner.

The typical Ubuntu GitHub Actions runner has up to 31 GB of disk space that is used by unnecessary packages that are not needed for many builds. This action clears up that space within 3 minutes and allows you to install the more storage intensive packages that are needed for your custom builds. Again. 16 thousand developers.

GitHub Actions is has a fairly terrible reputation. It has actually served as the reason for some notable projects, like Zig, to migrate to alternative platforms. The system has an unreasonable number of bugs for a product that is used by millions of developers.

As Zig mentions, the GitHub CEO said “Either you have to embrace the AI, or you get out of your career.” Not exactly kind or supportive words for the developers that are using your platform and are asking for quality of life improvements. It’s reasonable to assume that GitHub just doesn’t care about solving pain points of users.

That lack of care is what brings me to Super Smash Bros. Melee.

Here Comes a New Challenger

Super Smash Bros. Melee was released in 2001. When it came out, it was a popular party game, targeted towards families and children in particular. However, over time, it became a binding force for competition, driven by a grass-roots community of players.

It drew a large and growing viewer-base throughout the 2010s, peaking sometime in the 2010s with over 190 thousand viewers on Twitch. Players were sponsored and their livelihoods were supported in part by the community because of how good they were at the game.

But, just like GitHub Actions, Super Smash Bros Melee was unsupported by the developers. In fact, Nintendo actively tried to shut down tournaments and competitions, attempting to kill the large events that served as the pinnacle of competition. This didn’t happen just once, but multiple times.

Despite this, the community persisted. In fact, they modding the game heavily, adding features like in depth training modes and netcode (yes, I do see the irony in linking to a GitHub repo). These mods became staples of the community.

Incentive Alignment

There is a consistent theme across both of these communities. There’s the obvious: successful developers create things that are valuable to others. There’s even a lesson: even the champions of a product have thresholds for pain tolerance.

But there’s something particular about both of these stories that are notable today. It is common in startup culture to state that if you are solving a real problem, your chances of success drastically improve. The issue is that the converse does not hold true after a certain size. Dedicated communities can form around things, developing their own solutions as they’ve been left by the wayside.

On the surface, that seems like a good thing. But, when a hacked up solution becomes well known and commonly used, the moral of the story seems to become murky. These communities have entrenched these products deeper into their lives and signaled to the companies that they are not going to leave. In turn, the incentive for these companies to improve their products vanishes.

In some ways, it becomes an indicator that the story of “AI is going to replace software engineers” is a farce. GitHub has fully embraced the AI hype machine and somehow they are unable to solve pain points for their users. In a more cynical lens, it indicates that even with tool-assisted, supercharged engineers, GitHub doesn’t plan on improving parts of their product that are deeply meaningful to their users; they may be focused on margins and new flashy developments. The brand and positioning of GitHub feels questionable with that in mind. It doesn’t feel like the bastion for developers and budding engineers to show off their stuff and seek community that it once was.

In the case of Nintendo, the charitable interpretation almost leads to admiration. They are a company focused on providing children with formative life experiences in settings where they will always have fun. They refuse to support a competitive community that seeks glory and victory through hardship and anguish; because when winning matters, losing isn’t fun. Does that excuse them shutting down the joys of a community that aren’t harming people? Probably not, but at the end of the day it is a single game of the plethora of games in Nintendo’s catalog.

Now, what I can say also isn’t fun is thinking that my vibe-coded CI/CD has installed malware because a tool has a suspicious name, or relying on GitHub repos to be able to play a 25 year old game online.