5 ms·

I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to

by umvi 17d ago

I like the idea of jujutsu, but I must not operate at a scale where its "killer features" would truly shine. Git hardly ever gets in my way, I have never had to do complex octopus merges or anything like that. It's usually: feature branch, implement, merge, and occasionally fix a merge conflict. JJ seems like it's more for people that like to have tons of active branches that they are constantly switching between whereas I usually only work on 1 thing at a time. I've never thought to myself "git is so frustrating I wish there were something better" because I only use the same 5 commands over and over every day and they never get in my way. Not to mention jj has its own share of esoteric syntax with all the "@--+::" business and I'd have to re-wire my brain to remember those symbols instead of `ref~N`, etc.

y1n0 17d ago
I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-ids. The min identifiers in change-ids being highlighted. Being able to make commits and worry about the message later. Snapshots of changes while you are working serving as a tool agnostic undo. Painless and sensible cli args that are vastly more consistent than git. Superior conflict handling. You can “jj undo” anything and it works perfectly. It’s fabulous. > "@--+::" I have no idea what that means and I’ve never had to type anything remotely like it. The rev specification language is pretty elaborate but you don’t need to know it.
- mechazawa 16d ago
  isn't that what protected branches etc are supposed to fix in platforms like GitLab/GitHub/etc? My team has yet to break any important branches
- iota971 17d ago
  [flagged]
  - MrDrMcCoy 17d ago
    Maybe it's losing steam because it's stable and there's no demand for new features.
- ncphillips 17d ago
  Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
  - upslefts 16d ago
    Do you have a public example of an open source project that you are using that showcases those features? In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?
    - SAI_Peregrinus 16d ago
      > a public example of an open source project that you are using that showcases those features? IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.
- KingMob 16d ago
  IIUC, "@--+::" should read "all descendants of the children of the grandparents of the current commit". Or if it were a family tree, "all descendants of your parents and their cousins" (ignoring that family trees are way more constrained than DAGs). I have no idea why you would use that revset; I assumed it was just an example of revset's complexity and power. As a pragmatic matter, unless I'm scripting with revsets, I personally stick to a few go-to aliases.
- mb2100 16d ago
  They're not experienced with git, but still use the command-line? Interesting. Or would you think a jj GUI would help them?
  - yencabulator 16d ago
    [dead]
  - y1n0 14d ago
    CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough. But I don't tell my team what they have to use as long as it's compatible. The last thing I want to do is try to teach them a different VCS when they've spent time learning how to get by with git. I've told them about JJ, what I like, what pain points it solves for me. They are all adults, they can make their own decisions about it. JJ is for me. It helps me unwind some rather elaborate problems we've had with rebasing, or dealing with conflicts from bringing some old support branch up to date, or back porting some particular thing. It helps me create pretty clean MRs, break things up into smaller reviewable chunks, etc. You can do all this with git, but it's easier in JJ. In particular if you have to do shuffling and rebasing and conflict arise. JJ lets you solve conflicts asynchronously to rebasing. Git stops you in your tracks. There's some rerere thing that is supposed to help but give me a break. Git's a train wreck of dumpster fires. But it's still been basically better than everything else since svn. Until JJ IMHO. Valid arguments can be made for other things like maybe mercurial or even fossil. But JJ is the most pain-free vcs evolution I've seen. Mercurial's big failing was making too many critical things optional. It's the same screw-up riscv is going through now in the chip architecture space.
dcre 17d ago
A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it. Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.
- 1718627440 16d ago
  > - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase Can you explain this to me? I feel like Git is pretty easy there. - select oldest commit to modify - move the commits around with a mouse or the cursor - close the editor to apply Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me. Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
  - dullcrisp 16d ago
    It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
    - markalby 16d ago
      that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management. I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
nchmy 17d ago
if you make commits, then you are at the scale where its killer features would shine. In other words, even the most basic git usage is made easier with jj. If you care to learn more, there's tons of posts on hn and the broader web, so I won't bother sharing any links. I will say, though, that you should use it with jjui, which is a tremendous TUI for jj - you don't even really need to learn any of the actual jj syntax because it just handles it all for you.
brigandish 17d ago
jjui is the killer feature for me https://github.com/idursun/jjui https://github.com/idursun/jjui
ehsankia 17d ago
I disagree. Similar to you, 95% of the time I do the simple use case that I've memorized. The problem is that even after a decade of using Git, when I get into those 5% where something goes wrong, I have no idea how to actually solve it. None of it makes any sense in my head, and I have to search for a bunch of magical commands to run, or nuke things to get back to a good state. With JJ, it just makes sense. It's intuitive and clear. I have been able to recover without any help. Just the undo alone is basically a life saver. Rebasing and merge conflict resolution is so much simpler. Yes I probably won't use it to its full potential, but still, the little I do use makes 10x more sense than Git ever did.
dullcrisp 17d ago
I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.
- jrimbault 16d ago
  What if I _want_ a staging area?
  - steveklabnik 16d ago
    It’s a usage pattern, not a feature. It’s a really common way of working with jj: https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
  - stouset 16d ago
    I loved the staging area in git. That was the biggest thing that held me back from adopting jj for a long time, thinking it was a huge step backwards. It wasn’t. I was wrong. The staging area is just a commit like any other, only due to git’s design it has to be special-cased everywhere. In jj it’s just a commit. I do all my work on an unnamed commit on the tip of a branch. As I complete bits, I extract out cohesive sets of changes into new commits (split) or as patches of earlier commits (squash).
  - dullcrisp 16d ago
    Then you’ll probably appreciate being able to manipulate it the same way as any other change, but they could do a better job of marketing it that way.
SAI_Peregrinus 16d ago
IMO JJ allows a simpler "mental model" than git. Git is a DAG of commits, each of which is a node in the DAG. There's also a staging area that isn't a node in the DAG, and a working copy that also isn't a node in the DAG. The head nodes of every branch in the DAG are always named in git, and every node in the DAG also has a description. Nodes are immutable, but the edges between nodes are mutable so you can edit a node by replacing it with a new node & updating the edges. JJ is a DAG of commits. Each commit is a node. Nodes have stable identifiers, automatically generated. Nodes may have descriptions. Nodes may also have names (bookmarks) which get used for compatibility with git's branch names. Nodes are mutable, but by default nodes pushed to a remote will be immutable.
geoka9 16d ago
I would (probably) not bother with jj if I only had to work on my own codebases. As a developer on an active repo with lots of contributors and ceremony around PR reviews (~500 lines per PR, stacks, etc.) it's invaluable.

by umvi 17d ago

y1n0 17d ago

I was a skeptic until a few months ago. It’s my daily driver now. I’ve got sizable amount of people committing to the same repo, many are not skilled with git. So I deal with weird crazy “how did you ever get the repo into this state” issues not infrequently. JJ is just so low friction. The seamless and painless shuffling of commits, working up and down the commit chain without explicit rebasing, unchanging change-ids. The min identifiers in change-ids being highlighted. Being able to make commits and worry about the message later. Snapshots of changes while you are working serving as a tool agnostic undo. Painless and sensible cli args that are vastly more consistent than git. Superior conflict handling. You can “jj undo” anything and it works perfectly. It’s fabulous. > "@--+::" I have no idea what that means and I’ve never had to type anything remotely like it. The rev specification language is pretty elaborate but you don’t need to know it.

mechazawa 16d ago
isn't that what protected branches etc are supposed to fix in platforms like GitLab/GitHub/etc? My team has yet to break any important branches
iota971 17d ago
[flagged]
- MrDrMcCoy 17d ago
  Maybe it's losing steam because it's stable and there's no demand for new features.
ncphillips 17d ago
Same experience. At first I really didn’t get it and now I could never go back. The ease of rebasing, renaming, reordering, splitting, etc. Has drastically changed the way I work. My PRs are undoubtably much better now, and I am never afraid of messing up thanks to jj undo and the op log in general
- upslefts 16d ago
  Do you have a public example of an open source project that you are using that showcases those features? In your opinion, is jj losing steam? How do you feel about it requiring a CLA to contribute to, which would enable the developers to go closed-source and keep all the contributions of the community? Are you afraid of vendor lock-in?
  - SAI_Peregrinus 16d ago
    > a public example of an open source project that you are using that showcases those features? IMO that's almost fundamentally impossible. The whole point is that it makes maintaining a "clean" linear commit history easier than git, so by the time you push anything the observable differences are already gone. At best you just see a repo without any WIP-style commits, which can be done using more effort and git alone.
KingMob 16d ago
IIUC, "@--+::" should read "all descendants of the children of the grandparents of the current commit". Or if it were a family tree, "all descendants of your parents and their cousins" (ignoring that family trees are way more constrained than DAGs). I have no idea why you would use that revset; I assumed it was just an example of revset's complexity and power. As a pragmatic matter, unless I'm scripting with revsets, I personally stick to a few go-to aliases.
mb2100 16d ago
They're not experienced with git, but still use the command-line? Interesting. Or would you think a jj GUI would help them?
- yencabulator 16d ago
  [dead]
- y1n0 14d ago
  CLI is preferred from my point of view if only because it's the supported standard interface. VSCode's version control interface is reasonably close to a standard, and I love the tree view there. But generally I don't want to use random third party things because they either aren't consistent (i.e. now I have to learn what joe schmoe thinks a version control interface should be), or don't stick around long enough. But I don't tell my team what they have to use as long as it's compatible. The last thing I want to do is try to teach them a different VCS when they've spent time learning how to get by with git. I've told them about JJ, what I like, what pain points it solves for me. They are all adults, they can make their own decisions about it. JJ is for me. It helps me unwind some rather elaborate problems we've had with rebasing, or dealing with conflicts from bringing some old support branch up to date, or back porting some particular thing. It helps me create pretty clean MRs, break things up into smaller reviewable chunks, etc. You can do all this with git, but it's easier in JJ. In particular if you have to do shuffling and rebasing and conflict arise. JJ lets you solve conflicts asynchronously to rebasing. Git stops you in your tracks. There's some rerere thing that is supposed to help but give me a break. Git's a train wreck of dumpster fires. But it's still been basically better than everything else since svn. Until JJ IMHO. Valid arguments can be made for other things like maybe mercurial or even fossil. But JJ is the most pain-free vcs evolution I've seen. Mercurial's big failing was making too many critical things optional. It's the same screw-up riscv is going through now in the chip architecture space.

dcre 17d ago

A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase - make commits without having to come up with a branch name (I might make three versions of the same change in parallel to see how they compare) I see git is working on adding some of this under the history command. The revset language is really not esoteric: @ is head, @—- is two behind head. That’s about it. Part of it is that the sorts of shuffling I used to avoid because they were a pain in git (so I didn’t feel I needed them improved) are so easy in jj that I do them all the time.

1718627440 16d ago
> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase Can you explain this to me? I feel like Git is pretty easy there. - select oldest commit to modify - move the commits around with a mouse or the cursor - close the editor to apply Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me. Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
- dullcrisp 16d ago
  It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
  - markalby 16d ago
    that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management. I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.

nchmy 17d ago

if you make commits, then you are at the scale where its killer features would shine. In other words, even the most basic git usage is made easier with jj. If you care to learn more, there's tons of posts on hn and the broader web, so I won't bother sharing any links. I will say, though, that you should use it with jjui, which is a tremendous TUI for jj - you don't even really need to learn any of the actual jj syntax because it just handles it all for you.

brigandish 17d ago

jjui is the killer feature for me https://github.com/idursun/jjui https://github.com/idursun/jjui

ehsankia 17d ago

I disagree. Similar to you, 95% of the time I do the simple use case that I've memorized. The problem is that even after a decade of using Git, when I get into those 5% where something goes wrong, I have no idea how to actually solve it. None of it makes any sense in my head, and I have to search for a bunch of magical commands to run, or nuke things to get back to a good state. With JJ, it just makes sense. It's intuitive and clear. I have been able to recover without any help. Just the undo alone is basically a life saver. Rebasing and merge conflict resolution is so much simpler. Yes I probably won't use it to its full potential, but still, the little I do use makes 10x more sense than Git ever did.

dullcrisp 17d ago

I don’t know about you, but if you ever run git commit --amend, git rebase -i, git reset, git reset --hard, git stash, git add ., git push --force-with-lease, then these are all workflows that jujutsu makes easier and less error-prone.

jrimbault 16d ago
What if I _want_ a staging area?
- steveklabnik 16d ago
  It’s a usage pattern, not a feature. It’s a really common way of working with jj: https://steveklabnik.github.io/jujutsu-tutorial/real-world-workflows/the-squash-workflow.html https://steveklabnik.github.io/jujutsu-tutorial/real-world-w...
- stouset 16d ago
  I loved the staging area in git. That was the biggest thing that held me back from adopting jj for a long time, thinking it was a huge step backwards. It wasn’t. I was wrong. The staging area is just a commit like any other, only due to git’s design it has to be special-cased everywhere. In jj it’s just a commit. I do all my work on an unnamed commit on the tip of a branch. As I complete bits, I extract out cohesive sets of changes into new commits (split) or as patches of earlier commits (squash).
- dullcrisp 16d ago
  Then you’ll probably appreciate being able to manipulate it the same way as any other change, but they could do a better job of marketing it that way.

SAI_Peregrinus 16d ago

IMO JJ allows a simpler "mental model" than git. Git is a DAG of commits, each of which is a node in the DAG. There's also a staging area that isn't a node in the DAG, and a working copy that also isn't a node in the DAG. The head nodes of every branch in the DAG are always named in git, and every node in the DAG also has a description. Nodes are immutable, but the edges between nodes are mutable so you can edit a node by replacing it with a new node & updating the edges. JJ is a DAG of commits. Each commit is a node. Nodes have stable identifiers, automatically generated. Nodes may have descriptions. Nodes may also have names (bookmarks) which get used for compatibility with git's branch names. Nodes are mutable, but by default nodes pushed to a remote will be immutable.

geoka9 16d ago

I would (probably) not bother with jj if I only had to work on my own codebases. As a developer on an active repo with lots of contributors and ceremony around PR reviews (~500 lines per PR, stacks, etc.) it's invaluable.