6 ms·

Jujutsu worktrees are convenient (2024)

128 points by nvader 10mo ago

akabalanza 10mo ago
I consider git the best software ever written. I used to work with some other SVCs, and I cannot thinking on leaving git now. Somehow, I feel it like a limitation for my mind. I'm following this Jujutsu project, I'm genuinely curious to see what it can bring to the SVC scene.
- DarkNova6 10mo ago
  > I consider git the best software ever written. How so? I worked with Git all my professional life and I can't deny its efficacy. However, I would not call it un-improvable given all types of corner case issues I have had with it over the years.
  - akabalanza 10mo ago
    Maybe "best ever" is too bold, but both proven efficacy and mainstream popularity for over 15 years, without being a bulky thing everybody just accept (like vscode), I don't see many other software examples. Anyway, sorry for triggering you with the first bold statement! I actually wanted to emphasize the curiosity over jj.
    - gilrain 10mo ago
      > Anyway, sorry for triggering you with the first bold statement! Do you imagine someone to be triggered any time they correct you? Like, a sort of trigger you respond with whether accurate or not?
      - notrealyme123 10mo ago
        Found myself resonating with this a lot. Food for thought. Thanks for the comment.
    - oblio 10mo ago
      > without being a bulky thing everybody just accept Git isn't bulky in terms of RAM usage but it is bulky in terms of mental capacity that has to be allocated to it.
    - DarkNova6 10mo ago
      Not triggered at all, I was just asking a curious question :-)
    - fastasucan 10mo ago
      >Anyway, sorry for triggering you with the first bold statement! I actually wanted to emphasize the curiosity over jj. People does not have to be triggered to ask follow up questions. Its ok to even ask a challenging question as a response of a statement, without being an indication of their mood.
- skrebbel 10mo ago
  No software that has 3 names for the same thing (git stash —cached vs —keep-index wtf‽) deserves to be described as “the best ever written”
  - 1718627440 10mo ago
    That is not the same thing, --cached means use only the version cached in the index, --index means also use the index. What is the third thing you have in mind?
    - skrebbel 10mo ago
      That’s totally the same thing, they’re about what to do with the staging area but using 2 words for it (index and cache). The third term is “staging area” or the flag --staged for other commands. Any sane tool uses one word for each concept, not three. The Git CLI is full of this sort of shit and it drives me mad.
      - 1718627440 10mo ago
        The term "staging area" doesn't originate from Git itself, it was coined by third-parties. The single term you are looking for is index, it used to be cache, but was renamed long ago, and now cache only remains as a verb in some places.
        skrebbel 10mo ago
        It wasn’t renamed. If it was renamed they’d have deprecated --cached and introduced a new flag with a proper name. Also why does “git restore --staged” exist if the term “staging area” isn’t from Git? And why does “git add -i” have the words “staged” and “unstaged” all over the output? The answer to all these questions is that Git is made by people who care very deeply about data structures and very little about users. Git is needlessly difficult and this is just one of the many places where it shows. Don’t get me wrong, I’d much rather use a VCS with good data structures than one with good naming. Git is popular for a reason. But the bad CLI design is just such a waste because it makes Git needlessly hard to learn to the benefit of absolutely nothing. It’s not a tradeoff. It’s just shitty.
- Hammershaft 10mo ago
  I think Git is incredible version control hiding behind a terrible interface.
  - oblio 10mo ago
    An incredible version control system would probably be able to version empty folders, too. And other limitations I'm forgetting right now. It's good but I wouldn't call it incredible. I hope some day we do get a better SCM.
- OvbiousError 10mo ago
  Having worked with cvs and svn, git has been an absolute blast. That said, the first thing I do now in a repo is jj init --colocate. The fact alone that there is an operation log in jj, so you can easily revert your last command, or go back to any point you want, is mind blowing coming from git and having experienced frantically digging through the reflog. But that aside, the way to work with branches ahem bookmarks, commits, conflicts, just makes so much sense in a world where simultaneous feature branches are a thing.
  - gcr 10mo ago
    Keep in mind that you still need to occasionally run jj commands, even in collocated repositories Example: jj snapshots the working copy on any jj command but not any git command It’s a leaky abstraction
  - steveklabnik 10mo ago
    Colocation is the default these days, by the way.
- regularfry 10mo ago
  My journey was CVS->SVN->darcs->Hg->git. I can thoroughly recommend at least playing around with the others to see what you're missing. Darcs in particular I remember as having a much nicer model than either git or mercurial, but it had a horrible corner case behaviour. Pijul is supposed to fix that, but I haven't tried it yet.
  - spit2wind 10mo ago
    Have you used fossil? If so, what are your thoughts?
  - aj_hackman 10mo ago
    What motivated you to move from Mercurial? I'm still using HG for personal projects because it's so easy to self-host on a Raspberry Pi. Just `hg serve -p 8001` or whatever and I'm able to use TortoiseHG from any machine to easily stage commits.
- steveklabnik 10mo ago
  A lot of us who like jj felt similarly about git. Two pieces of software can both be good :)
- spit2wind 10mo ago
  That's interesting. I consider git the worst software ever written! I speak specifically of the UI. Obviously the underlying system works. Yet it's totally within reason that the UI has wasted trillions of money and many person years in lost productivity. Napkin math. It's easy to waste 30 minutes figuring out what the heck is going on after a command didn't work, or explaining what a detached head is to a newbie, or any number of completely avoidable issues were the UI better. Consider the 26.9 million developers in North America[1]. How does one estimate the average salary across NA? Some in SV make 3x that. Elsewhere, it's conceivable that people make considerably less. Let's just say 100k. That's 100,000÷52÷40=48/hr or 24 per half hour. Anyone with git, I think it's safe to say, has had at least one stupid issue that took 30 minutes because of the UI. That's 26.9×24=645,600,000 monies. In my experience and what I've seen of anyone who'a used git, 30 minutes is a gross underestimate. And people use git outside of NA. It's easily trillions in waste. https://en.wikipedia.org/wiki/Software_engineering_demographics https://en.wikipedia.org/wiki/Software_engineering_demograph...
- IshKebab 10mo ago
  Git is a clever idea with a terrible implementation. Definitely not the best software ever written.
  - adastra22 10mo ago
    Frustratingly, it isn’t an original idea either, and there were better implementations even at the time.
- antonvs 10mo ago
  > I consider git the best software ever written. You haven't used much software, I take it.
spider-mario 10mo ago
> I’ve been using Jujutsu(jj for short) as my defactor git cli frontend for a while now. “de facto” please.
- turboponyy 10mo ago
  Even better is "" since it's not really adding anything
  - keybored 10mo ago
    Coffee is my de facto morning beverage.
Zambyte 10mo ago
I'm glad they found a workflow that works for them, but > but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive. I have been using jj as my git client for 2 years now (wow), and I have never considered this to be disruptive. I just immediately switch to a new commit where I want to go, rather than making a new workspace to work in. Maybe it's a difference in the editor that I use (GNU Emacs) that makes this more natural?
- rafaelmn 10mo ago
  Build cache, packages and a few of other things get messed up when switching branches - if you need to do a "quick bug-fix and get back into the main thing" worktrees are really nice.
  - Zambyte 10mo ago
    I see. The projects I have been working on in the last few years don't take very long to compile, so build cache has not been a very big factor for me. I could see it being more important for projects that take a long time to build though.
- arccy 10mo ago
  if you don't do much in terms of accumulating open buffer/window sets, editor open at the specific line you were working on etc, then you'll feel it less. or things like just keeping the terminal history consistent with a change if you look at things like compile command outputs etc.
rafaelmn 10mo ago
So how is this different from git worktrees exactly ?
- rk06 10mo ago
  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
  - dubi_steinkek 10mo ago
    > 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.
    - Macha 10mo ago
      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
      - gcr 10mo ago
        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…)
        Macha 10mo ago
        jj support in editors is way behind git support.
        aseipp 10mo ago
        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.
mentalgear 10mo ago
Re Worktree/Spaces alternative: Why not just open up a new editor window ? > I usually use it when I’ve got one task I’m working on, but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.
- arccy 10mo ago
  your editor works on files on disk. worktrees / workspaces are what manage those files on disk in relation to your git repo.
michaelbuckbee 10mo ago
The usage of worktrees is seeing a big comeback in the era of AI assisted coding. I have a script that takes Github issues and spins them out into their own worktrees with corresponding stack. I can then run individual instances of Claude Code in each and easily flip between them.
- jackschultz 10mo ago
  Same. Never used worktrees before, but mapping a worktrees to tickets I’m assigned to for Claude to work on is really great. Heck with the ai, I even have it spin up a dev and test db for that worktree in a docker container. Each has their own so they don’t conflict on that front either. And I won’t lie, I didn’t write those scripts. The models did it all and can make adjustments when I find different work patterns that I like. This is all to the point of me wondering why I never did this for myself in the past. With the number of times I’m doing multiple parts of a codebase and the annoyance of committing, stashing, checking out different branch and not being able to go more quickly between when blockers are resolved.
- keybored 10mo ago
  What comeback? It’s been there for years and people who have use for them use them (or use git-clone(1) if they are not aware of them). It didn’t fall out of use at any point.
  - michaelbuckbee 10mo ago
    "Comeback" is probably the wrong word, maybe "uptick" in usage? Worktrees just fit particularly well for the scenario of developing multiple different features in parallel on the same codebase, which is a pattern that devs doing a lot of AI assisted development have.
wolfwyrd 10mo ago
Phil Haack has a neat script called tree-me[0] that takes a lot of the pain out of this in vanilla Git [0] https://haacked.com/archive/2025/11/21/tree-me/ https://haacked.com/archive/2025/11/21/tree-me/
- keybored 10mo ago
  That there are a few programs that massage git worktree output and adds some navigation and “management” I can understand. That there are seemingly dozens and people publish new ones every month I can’t.
jandudulski 10mo ago
`jj workspace add ../project-name-2` vs `git worktree add ../project-name-2` Sorry, but I don't get the improvement.
- bialpio 10mo ago
  The author doesn't mention this as an improvement to git, just showcases that an equivalent feature exists in jj. This is useful to me, a jj noob that was not aware it's possible.
- baq 10mo ago
  there isn't any. it's just possible in jj, which does not have feature parity with git and probably doesn't aim to have it anytime soon, if ever (not a contributor, so please don't quote me)
  - steveklabnik 10mo ago
    It depends on what you mean by "feature parity." jj has some features git doesn't, and git has some features jj doesn't. That's likely to be the case into the future, for sure. There's also like, some features of git aren't features in jj, but that doesn't mean you can't do that stuff with jj, it just works differently. The index or stashes, for example. In a literal sense, that's not parity, but in a logical sense, it is.
amluto 10mo ago
I want a variant of this where I make a worktree that has no ability to push anywhere including its parent. Instead the parent worktree pulls from it automatically. That way I can run some sandboxed workflow that might arbitrarily corrupt the work tree, possibly overwriting everything in it and symlinked from it, without losing data.
- Normal_gaussian 10mo ago
  The easy way to do this is to create a worktree and then just run it in some form of sandbox - e.g. a Docker container. In the worktree there is no .git directory, just a .git file which has a single line: "gitdir: <path to gitdir>". If your sandbox doesn't have access to the gitdir, you're golden.
  - gcr 10mo ago
    What if the sandbox needs access to the history? Imagine asking for help bisecting something, for example
    - deleted 10mo ago
      [deleted]
    - Normal_gaussian 10mo ago
      Then you'll probably want a clone; which will cost in more space. Just remember to remove the remotes. You could always use an overlayFS with the main (non-worktree) repo as the lowerdir (and then remove the remotes in the overlayFS), but that relies on you not trying to keep working on the git repo at the same time.
    - amluto 10mo ago
      Or if I want the sandbox to be able to create commits, which is extremely useful.
    - adastra22 10mo ago
      Mount the parent read-only.
tonyhart7 10mo ago
I like jujutsu kaisen too
janquo 10mo ago
It's not really usable to me as the workspace folder doesn't have .git in it, even though original repo is collocated and hence the git tools don't work there. I am forced to use git work trees with separate collocated JJ repo each.
- gcr 10mo ago
  Why are you using git tools within collocated jj repositories? I never understood that use case tbh
  - janquo 10mo ago
    Some company tooling / git oneliners from internet / and probably most relevant for me is git plugins for neovim / some personal scripts I would have rewrite to work both in .git and .jj repos
  - charlie-83 10mo ago
    JJ doesn't support git LFS is a common reason.
    - adastra22 10mo ago
      Is there a jj solution for git LFS?
      - steveklabnik 10mo ago
        There’s a PR open with basic support but hasn’t been merged yet. Large files in general is something the project would like to solve but it’s gonna take time.
- steveklabnik 10mo ago
  The fix for this is in progress.
donatj 10mo ago
I found worktrees unnecessarily painful in Git with little advantage over just having two copies of the repo. Your far better off just having a clone of your primary repo, and have your primary repo as a local remote. Both can have a remote for GitHub and a separate remote for each other.
- dylanowen 10mo ago
  I use work trees so my prototype can be open while I build my final code, but I never thought of local remotes! That'll be so much easier!
- loeg 10mo ago
  It's very useful when your repos are a significant fraction of disk space.
  - sph 10mo ago
    Given that hard drives are in the terabytes range, which repos are you checking out in the 250+ GB ranges? How many git users have this problem, really?
    - loeg 10mo ago
      It was the primary repo at my job at the time. Decades of history, migrated from SVN. Probably some ill-advised large binary blobs committed at one point or another. Surely it's a tiny fraction of git repos, if not users. But if it's a problem you have, worktrees are very useful.
- actinium226 10mo ago
  Genuinely curious, what did you find painful about it? A while back I found it annoying that I'd get errors when cleaning out my branches because they were checked out in a worktree I'd forgotten about, but git now highlights branches checked out in worktrees and has done so for a while.
fusslo 10mo ago
I don't understand the workflow that makes JJ more useful than git. I dont think I've even had the idea of having multiple worktrees going at once. What is the use case? The author mentions being blocked by CI flow. Don't you have CI running on gitlab or github? just commit and push the branch and run CI. The author mentions stashing the changes, but like.. if you're running against CI, isn't it in a state that is commitworthy? I don't see how creating a worktree in a new folder and opening a new editor is more convenient than creating a branch at a certain commit. I can understand if you need to run a CI or unit tests locally. Is that it? I am not attacking JJ, I genuinely can't understand its value in my current workflow.
- mastax 10mo ago
  You push branch A, then switch to branch B and start working on that. CI failed on branch A, so you stash branch B and switch back to branch A to fix it.
  - fusslo 10mo ago
    thanks, that makes sense. I don't see how a worktree is more convenient in that case. Maybe from the kind of work I do? either CI is failing because of something really simple, or something really complicated that means getting a product setup and producing debug messages. If it's a critical fix on branch A, then I'm not working on branch B. I'm testing branch A locally while CI does its thing
    - neandrake 10mo ago
      Worktrees are useful particularly because they look like entirely separate projects to your IDEs or other project tooling. They are more useful on larger projects with lots of daily commits. If you just use branches then whenever you switch, in the worst case, your IDE has to blow away caches and reconstruct the project layout or build the project fresh. On large projects this takes significant time. But switching your IDE to a different project, there are now two project and build caches to switch between.

128 points by nvader 10mo ago

I consider git the best software ever written. I used to work with some other SVCs, and I cannot thinking on leaving git now. Somehow, I feel it like a limitation for my mind. I'm following this Jujutsu project, I'm genuinely curious to see what it can bring to the SVC scene.

DarkNova6 10mo ago
> I consider git the best software ever written. How so? I worked with Git all my professional life and I can't deny its efficacy. However, I would not call it un-improvable given all types of corner case issues I have had with it over the years.
- akabalanza 10mo ago
  Maybe "best ever" is too bold, but both proven efficacy and mainstream popularity for over 15 years, without being a bulky thing everybody just accept (like vscode), I don't see many other software examples. Anyway, sorry for triggering you with the first bold statement! I actually wanted to emphasize the curiosity over jj.
  - gilrain 10mo ago
    > Anyway, sorry for triggering you with the first bold statement! Do you imagine someone to be triggered any time they correct you? Like, a sort of trigger you respond with whether accurate or not?
    - notrealyme123 10mo ago
      Found myself resonating with this a lot. Food for thought. Thanks for the comment.
  - oblio 10mo ago
    > without being a bulky thing everybody just accept Git isn't bulky in terms of RAM usage but it is bulky in terms of mental capacity that has to be allocated to it.
  - DarkNova6 10mo ago
    Not triggered at all, I was just asking a curious question :-)
  - fastasucan 10mo ago
    >Anyway, sorry for triggering you with the first bold statement! I actually wanted to emphasize the curiosity over jj. People does not have to be triggered to ask follow up questions. Its ok to even ask a challenging question as a response of a statement, without being an indication of their mood.
skrebbel 10mo ago
No software that has 3 names for the same thing (git stash —cached vs —keep-index wtf‽) deserves to be described as “the best ever written”
- 1718627440 10mo ago
  That is not the same thing, --cached means use only the version cached in the index, --index means also use the index. What is the third thing you have in mind?
  - skrebbel 10mo ago
    That’s totally the same thing, they’re about what to do with the staging area but using 2 words for it (index and cache). The third term is “staging area” or the flag --staged for other commands. Any sane tool uses one word for each concept, not three. The Git CLI is full of this sort of shit and it drives me mad.
    - 1718627440 10mo ago
      The term "staging area" doesn't originate from Git itself, it was coined by third-parties. The single term you are looking for is index, it used to be cache, but was renamed long ago, and now cache only remains as a verb in some places.
      - skrebbel 10mo ago
        It wasn’t renamed. If it was renamed they’d have deprecated --cached and introduced a new flag with a proper name. Also why does “git restore --staged” exist if the term “staging area” isn’t from Git? And why does “git add -i” have the words “staged” and “unstaged” all over the output? The answer to all these questions is that Git is made by people who care very deeply about data structures and very little about users. Git is needlessly difficult and this is just one of the many places where it shows. Don’t get me wrong, I’d much rather use a VCS with good data structures than one with good naming. Git is popular for a reason. But the bad CLI design is just such a waste because it makes Git needlessly hard to learn to the benefit of absolutely nothing. It’s not a tradeoff. It’s just shitty.
Hammershaft 10mo ago
I think Git is incredible version control hiding behind a terrible interface.
- oblio 10mo ago
  An incredible version control system would probably be able to version empty folders, too. And other limitations I'm forgetting right now. It's good but I wouldn't call it incredible. I hope some day we do get a better SCM.
OvbiousError 10mo ago
Having worked with cvs and svn, git has been an absolute blast. That said, the first thing I do now in a repo is jj init --colocate. The fact alone that there is an operation log in jj, so you can easily revert your last command, or go back to any point you want, is mind blowing coming from git and having experienced frantically digging through the reflog. But that aside, the way to work with branches ahem bookmarks, commits, conflicts, just makes so much sense in a world where simultaneous feature branches are a thing.
- gcr 10mo ago
  Keep in mind that you still need to occasionally run jj commands, even in collocated repositories Example: jj snapshots the working copy on any jj command but not any git command It’s a leaky abstraction
- steveklabnik 10mo ago
  Colocation is the default these days, by the way.
regularfry 10mo ago
My journey was CVS->SVN->darcs->Hg->git. I can thoroughly recommend at least playing around with the others to see what you're missing. Darcs in particular I remember as having a much nicer model than either git or mercurial, but it had a horrible corner case behaviour. Pijul is supposed to fix that, but I haven't tried it yet.
- spit2wind 10mo ago
  Have you used fossil? If so, what are your thoughts?
- aj_hackman 10mo ago
  What motivated you to move from Mercurial? I'm still using HG for personal projects because it's so easy to self-host on a Raspberry Pi. Just `hg serve -p 8001` or whatever and I'm able to use TortoiseHG from any machine to easily stage commits.
steveklabnik 10mo ago
A lot of us who like jj felt similarly about git. Two pieces of software can both be good :)
spit2wind 10mo ago
That's interesting. I consider git the worst software ever written! I speak specifically of the UI. Obviously the underlying system works. Yet it's totally within reason that the UI has wasted trillions of money and many person years in lost productivity. Napkin math. It's easy to waste 30 minutes figuring out what the heck is going on after a command didn't work, or explaining what a detached head is to a newbie, or any number of completely avoidable issues were the UI better. Consider the 26.9 million developers in North America[1]. How does one estimate the average salary across NA? Some in SV make 3x that. Elsewhere, it's conceivable that people make considerably less. Let's just say 100k. That's 100,000÷52÷40=48/hr or 24 per half hour. Anyone with git, I think it's safe to say, has had at least one stupid issue that took 30 minutes because of the UI. That's 26.9×24=645,600,000 monies. In my experience and what I've seen of anyone who'a used git, 30 minutes is a gross underestimate. And people use git outside of NA. It's easily trillions in waste. https://en.wikipedia.org/wiki/Software_engineering_demographics https://en.wikipedia.org/wiki/Software_engineering_demograph...
IshKebab 10mo ago
Git is a clever idea with a terrible implementation. Definitely not the best software ever written.
- adastra22 10mo ago
  Frustratingly, it isn’t an original idea either, and there were better implementations even at the time.
antonvs 10mo ago
> I consider git the best software ever written. You haven't used much software, I take it.

spider-mario 10mo ago

> I’ve been using Jujutsu(jj for short) as my defactor git cli frontend for a while now. “de facto” please.

turboponyy 10mo ago
Even better is "" since it's not really adding anything
- keybored 10mo ago
  Coffee is my de facto morning beverage.

Zambyte 10mo ago

I'm glad they found a workflow that works for them, but > but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive. I have been using jj as my git client for 2 years now (wow), and I have never considered this to be disruptive. I just immediately switch to a new commit where I want to go, rather than making a new workspace to work in. Maybe it's a difference in the editor that I use (GNU Emacs) that makes this more natural?

rafaelmn 10mo ago
Build cache, packages and a few of other things get messed up when switching branches - if you need to do a "quick bug-fix and get back into the main thing" worktrees are really nice.
- Zambyte 10mo ago
  I see. The projects I have been working on in the last few years don't take very long to compile, so build cache has not been a very big factor for me. I could see it being more important for projects that take a long time to build though.
arccy 10mo ago
if you don't do much in terms of accumulating open buffer/window sets, editor open at the specific line you were working on etc, then you'll feel it less. or things like just keeping the terminal history consistent with a change if you look at things like compile command outputs etc.

rafaelmn 10mo ago

So how is this different from git worktrees exactly ?

rk06 10mo ago
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
- dubi_steinkek 10mo ago
  > 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.
  - Macha 10mo ago
    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
    - gcr 10mo ago
      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…)
      - Macha 10mo ago
        jj support in editors is way behind git support.
      - aseipp 10mo ago
        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.

mentalgear 10mo ago

Re Worktree/Spaces alternative: Why not just open up a new editor window ? > I usually use it when I’ve got one task I’m working on, but for some reason I cannot proceed on it while eg the CI is running, but I also don’t want to leave the commit and close my code editor etc. It would be simple to just stash everything and later pop the stash, but it still feels disruptive.

arccy 10mo ago
your editor works on files on disk. worktrees / workspaces are what manage those files on disk in relation to your git repo.

michaelbuckbee 10mo ago

The usage of worktrees is seeing a big comeback in the era of AI assisted coding. I have a script that takes Github issues and spins them out into their own worktrees with corresponding stack. I can then run individual instances of Claude Code in each and easily flip between them.

jackschultz 10mo ago
Same. Never used worktrees before, but mapping a worktrees to tickets I’m assigned to for Claude to work on is really great. Heck with the ai, I even have it spin up a dev and test db for that worktree in a docker container. Each has their own so they don’t conflict on that front either. And I won’t lie, I didn’t write those scripts. The models did it all and can make adjustments when I find different work patterns that I like. This is all to the point of me wondering why I never did this for myself in the past. With the number of times I’m doing multiple parts of a codebase and the annoyance of committing, stashing, checking out different branch and not being able to go more quickly between when blockers are resolved.
keybored 10mo ago
What comeback? It’s been there for years and people who have use for them use them (or use git-clone(1) if they are not aware of them). It didn’t fall out of use at any point.
- michaelbuckbee 10mo ago
  "Comeback" is probably the wrong word, maybe "uptick" in usage? Worktrees just fit particularly well for the scenario of developing multiple different features in parallel on the same codebase, which is a pattern that devs doing a lot of AI assisted development have.

wolfwyrd 10mo ago

Phil Haack has a neat script called tree-me[0] that takes a lot of the pain out of this in vanilla Git [0] https://haacked.com/archive/2025/11/21/tree-me/ https://haacked.com/archive/2025/11/21/tree-me/

keybored 10mo ago
That there are a few programs that massage git worktree output and adds some navigation and “management” I can understand. That there are seemingly dozens and people publish new ones every month I can’t.

jandudulski 10mo ago

`jj workspace add ../project-name-2` vs `git worktree add ../project-name-2` Sorry, but I don't get the improvement.

bialpio 10mo ago
The author doesn't mention this as an improvement to git, just showcases that an equivalent feature exists in jj. This is useful to me, a jj noob that was not aware it's possible.
baq 10mo ago
there isn't any. it's just possible in jj, which does not have feature parity with git and probably doesn't aim to have it anytime soon, if ever (not a contributor, so please don't quote me)
- steveklabnik 10mo ago
  It depends on what you mean by "feature parity." jj has some features git doesn't, and git has some features jj doesn't. That's likely to be the case into the future, for sure. There's also like, some features of git aren't features in jj, but that doesn't mean you can't do that stuff with jj, it just works differently. The index or stashes, for example. In a literal sense, that's not parity, but in a logical sense, it is.

amluto 10mo ago

I want a variant of this where I make a worktree that has no ability to push anywhere including its parent. Instead the parent worktree pulls from it automatically. That way I can run some sandboxed workflow that might arbitrarily corrupt the work tree, possibly overwriting everything in it and symlinked from it, without losing data.

Normal_gaussian 10mo ago
The easy way to do this is to create a worktree and then just run it in some form of sandbox - e.g. a Docker container. In the worktree there is no .git directory, just a .git file which has a single line: "gitdir: <path to gitdir>". If your sandbox doesn't have access to the gitdir, you're golden.
- gcr 10mo ago
  What if the sandbox needs access to the history? Imagine asking for help bisecting something, for example
  - deleted 10mo ago
    [deleted]
  - Normal_gaussian 10mo ago
    Then you'll probably want a clone; which will cost in more space. Just remember to remove the remotes. You could always use an overlayFS with the main (non-worktree) repo as the lowerdir (and then remove the remotes in the overlayFS), but that relies on you not trying to keep working on the git repo at the same time.
  - amluto 10mo ago
    Or if I want the sandbox to be able to create commits, which is extremely useful.
  - adastra22 10mo ago
    Mount the parent read-only.

tonyhart7 10mo ago

I like jujutsu kaisen too

janquo 10mo ago

It's not really usable to me as the workspace folder doesn't have .git in it, even though original repo is collocated and hence the git tools don't work there. I am forced to use git work trees with separate collocated JJ repo each.

gcr 10mo ago
Why are you using git tools within collocated jj repositories? I never understood that use case tbh
- janquo 10mo ago
  Some company tooling / git oneliners from internet / and probably most relevant for me is git plugins for neovim / some personal scripts I would have rewrite to work both in .git and .jj repos
- charlie-83 10mo ago
  JJ doesn't support git LFS is a common reason.
  - adastra22 10mo ago
    Is there a jj solution for git LFS?
    - steveklabnik 10mo ago
      There’s a PR open with basic support but hasn’t been merged yet. Large files in general is something the project would like to solve but it’s gonna take time.
steveklabnik 10mo ago
The fix for this is in progress.

donatj 10mo ago

I found worktrees unnecessarily painful in Git with little advantage over just having two copies of the repo. Your far better off just having a clone of your primary repo, and have your primary repo as a local remote. Both can have a remote for GitHub and a separate remote for each other.

dylanowen 10mo ago
I use work trees so my prototype can be open while I build my final code, but I never thought of local remotes! That'll be so much easier!
loeg 10mo ago
It's very useful when your repos are a significant fraction of disk space.
- sph 10mo ago
  Given that hard drives are in the terabytes range, which repos are you checking out in the 250+ GB ranges? How many git users have this problem, really?
  - loeg 10mo ago
    It was the primary repo at my job at the time. Decades of history, migrated from SVN. Probably some ill-advised large binary blobs committed at one point or another. Surely it's a tiny fraction of git repos, if not users. But if it's a problem you have, worktrees are very useful.
actinium226 10mo ago
Genuinely curious, what did you find painful about it? A while back I found it annoying that I'd get errors when cleaning out my branches because they were checked out in a worktree I'd forgotten about, but git now highlights branches checked out in worktrees and has done so for a while.

fusslo 10mo ago

I don't understand the workflow that makes JJ more useful than git. I dont think I've even had the idea of having multiple worktrees going at once. What is the use case? The author mentions being blocked by CI flow. Don't you have CI running on gitlab or github? just commit and push the branch and run CI. The author mentions stashing the changes, but like.. if you're running against CI, isn't it in a state that is commitworthy? I don't see how creating a worktree in a new folder and opening a new editor is more convenient than creating a branch at a certain commit. I can understand if you need to run a CI or unit tests locally. Is that it? I am not attacking JJ, I genuinely can't understand its value in my current workflow.

mastax 10mo ago
You push branch A, then switch to branch B and start working on that. CI failed on branch A, so you stash branch B and switch back to branch A to fix it.
- fusslo 10mo ago
  thanks, that makes sense. I don't see how a worktree is more convenient in that case. Maybe from the kind of work I do? either CI is failing because of something really simple, or something really complicated that means getting a product setup and producing debug messages. If it's a critical fix on branch A, then I'm not working on branch B. I'm testing branch A locally while CI does its thing
  - neandrake 10mo ago
    Worktrees are useful particularly because they look like entirely separate projects to your IDEs or other project tooling. They are more useful on larger projects with lots of daily commits. If you just use branches then whenever you switch, in the worst case, your IDE has to blow away caches and reconstruct the project layout or build the project fresh. On large projects this takes significant time. But switching your IDE to a different project, there are now two project and build caches to switch between.