How Jujutsu Rethinks Git's Working Copy and Conflict Model
6 points by brunobrito
6 points by brunobrito
jj isn't a radical reinvention — it's a disciplined redesign.
👀🤨
A reasonable intro but also obviously LLM-written. There are several good intros and tutorials for jj that are written by humans who put care and effort into their work. Let’s not allow them to be displaced by slop.
So, the only post by this user, who happens to be a marketing guy at git-tower.com, is an obviously llm-generated post on git-tower.com?
Nice. This may be the best intro/enticement to jj I’ve seen. (Despite the somewhat nonhuman style.)
On worktrees, though, maybe I’m missing something and somebody can help. I use worktrees successfully for concurrent work (e.g., editing in one while running tests in another), but they fail for parallel work (actively editing in two worktrees at the same time). This is because they share a single oplog, so editing in both causes “divergence” which has to be constantly resolved and can lose edits.
Am I just holding it wrong? Git workspaces don’t seem to have a similar problem (I think because they have separate indexes).
Are you editing the same change in both workspaces? I can imagine that could cause issues and confusion.
Well, the use case was to have a separate set of changes in each workspace, so I can work on different PRs at the same time.
At some point when I switched workspaces and did a jj command, I would get a message that I needed to do jj workspace update-stale, and jj log would have a bunch of divergent changes in it. That would trigger a "reconcile divergent operations" algorithm, and that would lose working copy changes that hadn't been snapshotted by jj yet.
Maybe this only happened when I rebased one worktree on the other? But still, that would be a different set of changes. Anyway, if this is supposed to be a supported use case, I could pursue the issue further with the jj folks. It's one of my few disappointments with jj.
I find this happening when I do operations like “jj fetch”, that may change information in multiple workspaces. “Rebase one worktree on another” would be a similar example.
I agree that it can be annoying, I’m also not 100% sure how it would be fixed, but I’m also not an expert in these internals.
Hm, maybe it is only triggered by a small set of operations like fetch/rebase, and I could script my way out of it somehow. Right now to avoid it I'm using completely isolated repos with the same remote and push/fetching manually, which is clunky. This doesn't seem like an uncommon use case so I was hoping some jj genius already explained how to do it, but not that I've found.