Teammates who never touch jj don’t need to know it exists

Part 9 of 9.

This was the question that mattered most before adopting any of this for real work: what happens when a PR review comment comes from someone using plain git, or when I fall back to a plain git command myself out of habit. The answer turned out to be the least dramatic part of the whole series - nothing special happens, because colocated mode means jj is reading and writing the same Git object database everyone else is. A commit pushed with git push and a commit pushed with jj git push are the same kind of object on the other end.

The part I did want to verify rather than take on faith: what if someone runs git fetch or git pull directly inside my colocated working directory - an IDE’s built-in Git panel doing it silently is the realistic version of this. jj auto-imports the current Git-side refs at the start of the next jj command, and auto-exports its own state back to .git right after, so the two views never actually drift out of sync. I tested it by fetching with plain git fetch and then just running jj log - the new remote commits were there, no jj git fetch needed first.

Rebasing onto a teammate’s ordinary git push is identical to the routine from the previous post: jj git fetch, jj rebase -d main. If it conflicts, jj records the conflict in the commit and lets me keep working rather than freezing the whole repo in a mid-rebase state - conflict markers in the file look exactly like Git’s, so resolving by hand instead of via jj resolve works fine too.

Nine posts in, the summary I’d give someone else considering this: colocated jj is a personal upgrade with essentially no coordination cost. Nobody else on the team has to adopt anything, change any workflow, or even find out, unless they ask why your jj log output looks nicer than their git log --graph.