5 ms·

So how is this different from git worktrees exactly ?

by rafaelmn 10mo ago

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.
    - steveklabnik 10mo ago
      The fix for having worktrees be colocated is in progress. Not sure when it’ll be done but it’s coming.
  - rk06 10mo ago
    wtf? it can diverge from git? wasn't git compatibility it's main pro?
    - SatvikBeri 10mo ago
      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.
    - steveklabnik 10mo ago
      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.
    - aseipp 10mo ago
      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.
    - xboxnolifes 10mo ago
      git is the storage layer. JJ's commands do not have to, and never did, match git one-to-one.
    - antonvs 10mo ago
      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.
- gcr 10mo ago
  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.
- antonvs 10mo ago
  > 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.
weinzierl 10mo ago
In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main. 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.
- htgb 10mo ago
  That sounds like a nice improvement, just like many other aspects of jj! 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.
  - weinzierl 10mo ago
    The detached head is what I meant with keeping it on the branch while not keeping it on the branch. 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.
- rafaelmn 10mo ago
  OK nice to know. Don't find this limiting for my flow but will keep in mind if I decide to give JJ a try.
- PurpleRamen 10mo ago
  > In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main. 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?

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.
  - steveklabnik 10mo ago
    The fix for having worktrees be colocated is in progress. Not sure when it’ll be done but it’s coming.
- rk06 10mo ago
  wtf? it can diverge from git? wasn't git compatibility it's main pro?
  - SatvikBeri 10mo ago
    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.
  - steveklabnik 10mo ago
    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.
  - aseipp 10mo ago
    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.
  - xboxnolifes 10mo ago
    git is the storage layer. JJ's commands do not have to, and never did, match git one-to-one.
  - antonvs 10mo ago
    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.
gcr 10mo ago
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.
antonvs 10mo ago
> 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.

weinzierl 10mo ago

In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main. 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.

htgb 10mo ago
That sounds like a nice improvement, just like many other aspects of jj! 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.
- weinzierl 10mo ago
  The detached head is what I meant with keeping it on the branch while not keeping it on the branch. 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.
rafaelmn 10mo ago
OK nice to know. Don't find this limiting for my flow but will keep in mind if I decide to give JJ a try.
PurpleRamen 10mo ago
> In git you can have only one worktree per branch. For example, if you have a worktree on main you cannot have another one on main. 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?