Jujutsu worktrees are convenient (2024)

there is no difference as jj is only a frontend to git.

author me tions that git cli require multiple steps when there are unstaged changes.

I don't know if git has one liner cli command for it as i myself use gitextn to create worktrees

> there is no difference as jj is only a frontend to git.

That's not really true in this case, as the worktree feature from jujutsu is not implemented on top of git worktrees.

This is kind of unfortunate in this case as it breaks some tooling since the extra trees are not collocated with git, like editor inline history/blame or agents that know to look in git history to fix their mistakes

jj may use git as (one of) its backing stores, and its collocation offers some compatibility at the cost of important tradeoffs, but it isn’t intended to be a git frontend.

isn’t it strictly better to use your editor’s JJ support and ask Claude to use jj?

(I personally think jj shouldn’t support collocated repositories, but happy to learn what others see in them…)

wtf? it can diverge from git?

wasn't git compatibility it's main pro?

jj support in editors is way behind git support.

You can still use git worktrees in a colocated repository. jj workspaces are a different, but similar capability that provide some extra features, at the cost of some others.

The fix for having worktrees be colocated is in progress. Not sure when it’ll be done but it’s coming.

Yes, jj is its own VCS with pluggable backends.

Google uses it with Piper, their centralized VCS.

Being compatible and being purely a frontend aren’t the same thing.

To be technical, it's more that it can read and write the on-disk Git format directly, like many other tools can.

I think the easiest way to conceptualize it is to think of Git and jj as being broken down into three broad "layers": data storage, algorithms, user interface. Jujutsu uses the same data storage format as Git -- but each of them have their own algorithms and user interface built atop that storage.

I think the biggest benefits of colocation are, in rough approximation of the order I encounter them:

1) Various read-only editor features, like diff gutters, work as they usually do. Our editor support still just isn't there yet, I'm afraid.

2) Various automation that tends to rely on things like running `git` -- again, often read-only -- still work. That means you don't have to go and do a bunch of bullshit or write a patch your coworker has to review in order to make your ./run-all-tests.sh scripts work locally, or whatever.

3) Sometimes you can do some kind of nice things like run `git fetch $SOME_URL` and then `git checkout FETCH_HEAD` and it works and jj handles it fine. But I find this rare; I sometimes use this to checkout GitHub PRs locally though. This could be replaced 99% for me by having a `jj github` command or something.

The last one is very marginal, admittedly. Claude I haven't had a problem with; it tends to use jj quite easily with a little instruction.

git is the storage layer. JJ's commands do not have to, and never did, match git one-to-one.

> there is no difference as jj is only a frontend to git.

It's easy to get this impression because git is so dominant, so most people using jj use it as a frontend to git.

But jj is a fully self-contained version control system. It always stores all its commits, branches, and other repo metadata in the .jj directory. You can use it standalone like this without ever using git.

Git integration is optional, and works by importing from or exporting to Git. Internally, jj still manages its own history. Git support is just a bridge.

No, that's just a practical approach to supporting migration to jj.

If we want to improve systems, we need to be able to migrate conveniently from older systems to better ones.