So how is this different from git worktrees exactly ?
replies(2):
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
That's not really true in this case, as the worktree feature from jujutsu is not implemented on top of git worktrees.
I personally find this annoying. I usually like to keep one pristine and always current working copy of main (and develop if applicable) around for search and other analysis tasks[1]. Worktrees would be ideal and efficient but due to the mentioned restriction I have to either waste space for a separate clone or do some ugly workarounds to keep the worktree on the branch while not keeping it on the branch.
jujutsu workspace are much nicer in that regard.
[1] I know there are tons of ways search and analyze in git but over the years I found a pristine working copy to be the most versatile solution.
Tools should adapt to us and not the other way around, but if you are stuck with git, there's a slightly different workflow that supports your use case: detached head. Whenever I check out branches that I don't intend on committing to directly, I checkout e.g. origin/main. This can be checked out in many worktrees. I actually find it more ergonomic and did this before using worktrees: there are no extra steps in keeping a local main pointer up to date.
The complication comes from trying to stay current. With a regular worktree I could just pull, but now I have to remember the branch, fetch all and reset hard to the remembered branch.
You can detach the worktree from the repo, and checkout multiple branches at the same time to different locations. Not sure if this also allows checking out the same branch to multiple locations at the same time. You can also have a swallow clone, so you don't have to waste space for the full repos history. So at the end you still have to waste space for each worktree, but this isn't something jujutsu can avoid either, or can it?
Also, if you end up relying on it for space reasons, worth knowing that cloning from a file:// url switches the hardlink mechanism off so you end up with a full duplicate again.
git worktree add ..\repo -b wt-main --track origin/main
And to be honest, after being disciplined to always do that, I very rarely get error message saying that the branch I want to check out is already checked out in other worktree. Before that, I regularly had a situation when I checked out main branch on second worktree to see the current state of the repo (because my main worktree had a work in progress stuff) and after some time when I finished work on main branch, I tried to check out main branch on my main worktree and got the error. Because I totally forgot that I checked it out some time ago in the other worktree.
Google uses it with Piper, their centralized VCS.
Being compatible and being purely a frontend aren’t the same thing.
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.
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.
Well, that is true, but a branch is nothing more than an automoving label, so I don't see how that is limiting at all. You can have as many branches as you like and you can also just checkout the commit.
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.