VisualJJ

Stacked PRs without cascading rebases

You've split a feature into four dependent PRs. The reviewer leaves a comment on PR #1. You fix it. Now PRs #2, #3, and #4 are all out of date, their branches point at commits that no longer exist, and you're staring at an interactive rebase that's about to re-surface the same conflict three more times. Force-push each branch. Every review comment that was pinned to a line now floats over a line that isn't there.

By round two, most teams have quietly stopped stacking.

Why stacks are worth it anyway

Smaller PRs get reviewed faster. Reviewers catch more problems when the change is focused. Shipping stays incremental even on large features. The cycle time between "feature started" and "first piece in production" drops from weeks to days.

Teams that stack well ship noticeably faster than teams that don't. The problem isn't the idea — it's the maintenance cost of keeping a stack coherent in Git.

The four things that break

Every stacked-PR workflow on Git runs into the same four frictions:

  1. Splitting is expensive. Moving a hunk from PR #3 down to PR #1 means rewriting #1, rebasing #2 and #3 on top, and force-pushing all three. Most of the time you decide it's not worth it and ship a 10,000-line PR instead.

  2. Updating the base cascades. Fix a comment on PR #1 and every PR above it needs to rebase. If the fix introduced a line that conflicts with edits in #2, you fix the conflict in #2. Then the same conflict shows up in #3. Then again in #4. The same resolution, typed four times.

  3. Force-push destroys review state. Every branch you force-push detaches reviewers' comments from the code they were written about. Reviewers who came back on Friday to check your updates are now looking at phantom comments on lines that shifted.

  4. Tooling demands team buy-in. The existing solutions — external stacking tools, merge queues — tend to require that every reviewer install the same client, or lock you into a single Git host. On a team where not everyone wants to switch, the stacking tool becomes a sub-team thing, and then it's another round of coordination.

So most people stop stacking and ship bigger PRs. The bottleneck moves from your branch to the reviewer's attention span.

What changes with Jujutsu

Jujutsu (JJ) is a version control system that works with your existing Git repositories and Git host. You don't give up GitHub, you don't migrate history, you don't ask teammates to switch. Under the hood, JJ tracks your work differently, and that difference is where the stacking friction disappears.

Three properties of JJ's model matter here:

Changes have stable identity across rewrites. In Git, every edit to a commit produces a new commit with a new hash. In JJ, a change has an ID that survives rewrites — shape it, rebase it, amend it, and it's still the same change. That's what lets "PR #2" keep being PR #2 even after you've rebased it three times.

Conflicts are data, not a modal. When a rebase produces a conflict, Git stops and demands you resolve it before you can do anything else. JJ stores the conflict in the commit, lets you keep moving, and you fix it when you're ready. The conflict doesn't block your flow.

Descendants auto-rebase. When you edit a change, every change on top of it automatically rebases onto the edited version. If the edit introduced a conflict, you resolve it once — not once per descendant. The resolution propagates.

Put these together and the four frictions collapse. Splitting is cheap because nothing cascades. Updating the base is a single edit because the stack adjusts itself. Conflicts get resolved once. And because JJ is Git-compatible, your teammates see ordinary PRs on GitHub — they don't install anything.

What VisualJJ adds

JJ's CLI is only the beginning. VisualJJ gives you the visual surface where stacking becomes obvious:

  • The stack as a graph. The tree shows every change in every PR, numbered "1/3", "2/3", "3/3" so you always know where you are.
  • Edit any change, anywhere in the stack. Double-click to jump in, make your fixes, and every descendant rebases onto the edited version automatically. One Push sends all the updated branches to GitHub — you don't push four branches one at a time.
  • PR descriptions stay in sync. VisualJJ keeps each PR's description updated with the full stack list, so reviewers see the whole picture on GitHub without clicking through.
  • Auto-fetch. Your tree stays current — when teammates ship, you see it within a minute, and you can rebase before the conflicts pile up.

Nothing here requires your teammates to install VisualJJ. They review ordinary GitHub PRs. The only workflow that changes is yours.

No SaaS between you and GitHub

VisualJJ talks to GitHub directly from your editor, using the credentials you already have. No third-party service sits in the middle of your PRs, no extra accounts to sign the team up for, and nothing new to trust with your code.

When this earns its place

  • You have a feature that splits naturally into three or more dependent pieces, and you'd rather ship them incrementally than as one blob.
  • Review rounds are the bottleneck on your team, and smaller PRs would get reviewed faster — if the maintenance cost weren't prohibitive.
  • Your main branch moves multiple times a day because you're on a team of ten to twenty engineers who ship frequently.
  • You've tried stacking before and abandoned it because the upkeep wasn't worth it.
  • You'd rather not add a SaaS to your PR workflow — or can't get the team to adopt one.

Try it

  1. Install VisualJJ in your editor.
  2. Start a 30-day free Pro trial and turn on Auto-update PR descriptions and Auto-fetch changes from remote in Project Info.
  3. Pick a feature you'd normally ship as one PR. Split it into three dependent ones.
  4. Make a change to the bottom of the stack. The rest rebase on top of it automatically; one Push sends the updated branches to GitHub.

Your teammates don't need to do anything. They see the same GitHub PRs they always see, in a slightly cleaner order.