Why Some Developers Are Turning to Jujutsu to Escape Git Fatigue

The problem: "Git rigour fatigue"

When a feature stretches across several weeks, developers often start with a handful of well‑structured commits – one for type definitions, another for database helpers, a third for UI work, and so on. In theory this makes code review a step‑by‑step walk through a logical story. In practice, keeping each commit perfectly scoped becomes a source of friction.

• WIP commits pile up – temporary debugging changes, half‑finished UI tweaks, and quick schema tweaks get mixed together.
• Re‑ordering or fixing early commits can break later ones, leading to a cascade of merge conflicts.
• Git’s built‑in tools (git rebase -i, git commit --amend) feel heavyweight for the day‑to‑day churn of a large feature.

Developers call this mental overhead git rigour fatigue.

Enter Jujutsu

Jujutsu (jj) is a relatively new, Mercurial‑inspired VCS that stores history as a directed acyclic graph of changesets rather than the linear commit chain Git uses. Two commands are central to the workflow described by ikesau:

• jj absorb – merges the changes of a later commit into an earlier one, automatically assigning hunks based on file‑level proximity.
• jj squash – collapses a range of commits into a single changeset, optionally letting you interactively pick which hunks go where.

The author’s technique looks like this:

1. Work freely – make whatever commits feel natural, even if they mix concerns ("red" for types, "blue" for UI, etc.).
2. Create placeholder commits that label the intended logical groups (jj new -B messy-first -m 'red').
3. Squash the whole mess into a single “everything” commit.
4. Iteratively re‑squash the “everything” commit back into the labeled placeholders, using jj squash -i to hand‑pick hunks.
5. Result: a clean, logically ordered history with no intermediate conflicts, because the final state of the “everything” commit is already conflict‑free.

What the community is saying

Positive signals

• Reduced context switching – developers report being able to stay in the flow of implementation, only cleaning up when the feature is complete.
• Better handling of temporary state – debugging prints, experimental branches, and quick schema tweaks can live together without polluting the final history.
• Interactive squashing works well when the feature’s final shape is known, because the tool can move hunks around without the merge‑conflict pain that Git’s interactive rebase sometimes incurs.

Counter‑arguments

• Compilation safety – because intermediate commits may not compile, CI pipelines that run on every push lose their usefulness. Teams that rely on early feedback might find the approach risky.
• Tool adoption cost – Jujutsu is not as ubiquitous as Git. New contributors need to install the binary, learn its command set, and understand its graph‑based model, which can be a barrier for open‑source projects.
• Limited ecosystem – integrations with popular platforms (GitHub, GitLab) are still in early stages. Pull‑request diffs are rendered using Git under the hood, so teams may need extra steps to translate Jujutsu history back to Git for code review.
• Potential for “laundry‑pile” commits – if the final tidy‑up is delayed too long, the “everything” commit can become massive, making the interactive squashing step time‑consuming and error‑prone.

How this fits into broader trends

The technique mirrors a larger movement toward post‑commit hygiene: write code first, refactor history later. Similar ideas appear in tools like git commit --fixup + git rebase --autosquash, or in Mercurial’s histedit. Jujutsu’s graph model simply makes the “re‑parenting” operation feel lighter, which explains why a subset of developers are experimenting with it for large‑scale feature work.

Should you try it?

If your team values a clean PR history but finds strict Git discipline draining, give Jujutsu a test run on a side‑branch.

1. Clone the repo with jj clone <url>.
2. Follow the author’s pattern: work freely, then jj squash back into logical placeholders.
3. Before merging, export the cleaned history to Git (jj export --git) so CI and code‑review tools can operate as usual.

If compile‑time safety is a hard requirement, you may need to keep intermediate commits buildable or supplement the workflow with a temporary CI run after the “everything” commit.

Bottom line

Jujutsu offers a pragmatic way to postpone commit hygiene until the end of a feature, reducing the mental load of strict Git discipline. The trade‑off is a reliance on a less‑common tool and the risk of non‑compiling intermediate states. Teams that can afford a short learning curve and have a clear hand‑off point for history cleanup may find the approach a worthwhile antidote to git rigour fatigue.