Key Moments

Onboarding & docs are weak: They highlight that JJ’s official website has limited documentation, there’s no clear “I’m a Git user, how do I switch?” guide, and the flexibility of many possible workflows can be overwhelming for newcomers.

Tutorials that stop halfway: Wojciech describes learning JJ via Steve Klabnik’s tutorial (great for basics and GitHub PRs), but notes it stops at a “to be continued” point and doesn’t cover advanced workflows like stacked PRs or mega merges.

Rebase is harder to discover: Wojciech explains that he frequently has to look up how to “rebase” his feature branches in JJ, because the commands are less obvious than in Git and official docs feel more like technical references than user tutorials.

AI help is hit-and-miss: They mention that asking AI tools about JJ used to produce outdated or incorrect commands; it’s improved, but still tends to lag behind JJ’s latest versions.

Powerful primitives, missing batteries-included UX: JJ gives very low-level, powerful tools (like refsets and named bookmarks), but many higher-level conveniences are missing, forcing users to copy snippets from Discord or write custom commands (like tug to move bookmarks).

Refsets are strong but complex: Refsets are described as a powerful language for describing revision sets, but way too advanced for beginners; newcomers shouldn’t be forced to learn them in their first months just to get common workflows.

Bookmark and branch friction: Because named bookmarks in JJ effectively stand in for Git branches, users must manually move and update them, which can feel as clumsy as moving tags in Git unless you script it yourself.

Tagging still done in Git: Wojciech shares that for release tagging he still drops down to raw Git commands, since he doesn’t have a smooth JJ-based tagging workflow.

GitHub & divergent commits: A big pain point is that when pushing/pulling from GitHub, commits may get different IDs, resulting in “divergent changes” that JJ can’t automatically reconcile, so users must manually pick which ones to keep.

Ecosystem still catching up: They mention tools like Tangled and an unreleased JJ-focused hosting platform being built by core maintainers, hoping it will be for JJ what GitHub was for Git.

Performance & features on large repos: From community feedback, they note JJ can be slower on very large repos due to tracking every file change, and features like workspaces aren’t supported yet.

Interactive rebase vs JJ workflows: Some users miss Git’s powerful interactive rebase that can reshuffle many commits at once; in JJ similar effects often require more manual work or complex refsets, though many gaps already have open issues and planned improvements.

Real-world experience is still positive: Despite the rough edges, both hosts say working with GitHub is still nicer through JJ than pure Git, especially when checking out others’ branches and avoiding git stash/cleanup chores.

Maturity and trade-offs: They frame JJ’s current state as “growing pains” of a young tool (v0.33), with drawbacks that are small compared to the benefits for their everyday work.

Closing encouragement: They stress they’ve been JJ-only for months, recommend listeners give it a try alongside Git, and suggest re-listening to the previous positive episode or watching their Brain Picks YouTube video for a more enthusiastic, hands-on view.

👋 Visit us on https://brainsandbeards.com/

https://brainsandbeards.com/

Our video about JJ: https://www.youtube.com/watch?v=J2f3Pj58wTg

Key Moments:

Introducing JJ (Jujutsu): The hosts explain what JJ is, where it came from, and how it works as a Git-compatible version control tool.

Why JJ works alongside Git: They highlight that JJ can be used on top of existing Git repositories, allowing silent adoption without requiring team-wide changes.

Undo/redo & operation log: A major selling point — JJ’s intuitive ability to undo any action and track every change, unlike Git’s cryptic reflog.

Working with changes, not commits: JJ’s model fits developers’ real workflow better, allowing editing of earlier changes, easy restructuring, and meaningful commit histories.

Goodbye git stash: JJ removes the need for stashing or temporary commits when switching context, making branch changes effortless.

MegaMerge capability: JJ allows temporary merging of multiple branches for testing without permanent commits — something Git can’t replicate cleanly.

Improved review workflow: JJ makes checking out others’ branches and cleaning up afterward much easier compared to Git’s messy local branch management.

Tools & ecosystem: Terminal UIs, graphical interfaces, and merge tools already support JJ, making it beginner-friendly.

Path to wider adoption: Discussion about the future potential of a “JJ hub” that works natively with change IDs.

Closing reflections: Both hosts emphasize that switching to JJ was easier and more valuable than expected — enough to inspire them to restart the podcast.

👋 Visit us on https://brainsandbeards.com/

https://brainsandbeards.com/

Key Moments:

• Documentation comes in different forms like code comments, README files, external documentation in Confluence, and architectural decision records (ADRs).
• Code comments can become outdated over time as the code changes, so it's better to rely on clear naming, TypeScript types, and unit tests to document code.
• README files should focus on project-specific setup instructions rather than general language/framework documentation, and link to external docs when possible.
• External documentation is better suited for business context, team decisions, and diagrams that involve multiple teams. It's easier for others to contribute to compared to code docs.
• Using a shared terminology ("domain language") is important for communication between teams working on the same codebase or product. This vocabulary should be documented.
• ADRs are useful for documenting past architecture and design decisions in case they need to be revisited. They improve decision making and prevent rehashing the same discussions.
• Writing documentation forces one to better understand a topic. Developers should practice writing to improve their communication and learning.
• Tests can double as a form of documentation, like regular expressions explained through example test cases.
• Commit messages should be concise and avoid too many changes in one commit to allow for informative messages.
• TypeScript's "expect error" is better than "ignore" for documenting expected errors in code.

👋 Visit us on https://brainsandbeards.com/