43 ms·

Switch to Jujutsu Already: A Tutorial

116 points by birdculture 1y ago

palata 1y ago
I have been trying Jujutsu for a few weeks. It's cool and I like trying new things. I wouldn't say that it's so much better than git, though; there is nothing that I miss in the projects where I use git. On the other hand, I have issues with Jujutsu, one of which completely prevents me from using it in some projects: * No support for git submodules. One can dislike submodules as much as they want, if I need to contribute to a repository using them, I can't use Jujutsu. * The signing support is very annoying with a security key. Even if I configure 'sign-on-push', it will access the security key every time it tries to check the signature, which is pretty much every `jj st` or `jj log` after something has changed locally. I don't need to check my own signatures, IMO they should be checked on fetch and on push. * There is no way to configure a 'defaultKeyCommand' like in git, which I now rely on (because I have multiple security keys).
- stavros 1y ago
  Yeah, it sounds like you have specific requirements that don't let you use jj until it gets support for those. That's fair.
- ahartmetz 1y ago
  I also have that problem with submodules. Of course they are crap, but the project uses them.
itchynosedev 1y ago
I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git. In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.
- stavros 1y ago
  Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?
  - 1718627440 1y ago
    I also use them, because I don't know a better alternative. I want it the subproject's version to be defined in a parent's commit and also modify the subproject. Changes to the subproject should stay in the commit history of the subproject Is there a better way?
  - itchynosedev 1y ago
    I noticed some of my hybrid repositories were slow on regular git commands (eg log) and running garbage collection manual resolved it. Perhaps, jj created a lot of unreachable objects?
    - 1718627440 1y ago
      JJ invites rebase heavy workflows and since it uses git, commits are still immutable, so it needs to create new commits. So this sounds quite expected.
- ljm 1y ago
  One of the bigger selling points of JJ just wouldn't work so well without larger team buy in for me: the ability to push stacked PRs. I like the idea of it, but there's so much inertia around typical git workflows that revolve around the GH pull request model (with the only difference being the use of trunk based dev or some git-flow like branching strategy) that it'd be hard to change without a lot of buy in. I still think back to Phabricator and its approach to code review, noting that it sadly never got wider traction despite having notable benefits over a completely entrenched status quo.
roxolotl 1y ago
> Jujutsu, in contrast, is more like playing with Play-Doh. You take a lump, cut it into two, shape one piece into something, give it a name, change your mind, give it another name, take a bit of the second piece and stick it on the first piece, and generally go back and forth all around your play area, making changes. I love this description and it describes how I work with git. When I’m doing things locally I’m constantly committing small wip commits. When I get something the way I like it I’ll interactive rebase/just back it all up, and then create the perfect little boxes. I guess I should try jujutsu since it sounds like it might be even more for me. Although if you can’t get to the perfect boxes at the end I don’t know if I’d like it.
- stavros 1y ago
  I'll say that Jujutsu makes the way to get to the perfect boxes really friction-free.
- simgt 1y ago
  That's how I feel like working with git locally using a combination of basic commands and gitup (https://gitup.co/ https://gitup.co/), that may be why I couldn't really get the selling point of jj when I tried it a couple weeks ago. The only part that piqued my interest is merges being always successful and conflicts just sitting in the tree, waiting patiently to be resolved... It's the next logical step after being able to commit without synchronizing when we all moved away from SVN.
  - 1718627440 1y ago
    > gitup (https://gitup.co/ https://gitup.co/) That looks actually nice, but it seams to require macOS.
- nchmy 1y ago
  I think you would love jj then. It is dead-simple to just move things around - branches/bookmarks, commits and even single lines of code within a diff. jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) makes it all that much easier too
jakebasile 1y ago
I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code base, nor do I need to deal with possible inconsistencies by using a different frontend on my end. It's cool that it exists, and it's impressive that it is built on top of git itself. If you (like the author) want to use it, then more power to you. But I have yet to be convinced by any of these articles that it is worth my time to try it since nearly all of them start from a point of "if you hate Git like me, then try this thing". If anyone has a link to an article written from the point of view of "I love or at least tolerate git and have no real issues with it, here's why I like JJ," then I'd be glad to read it.
- stavros 1y ago
  I don't hate git, I like it fine and, until recently, used it exclusively on all my projects (I still use it non-exclusively). Here's an article that's written from that viewpoint: https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/ https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... That having been said, I didn't hate Subversion either. It was fine.
  - jakebasile 1y ago
    Yeah I definitely hated Subversion, which helped push me to try Git back in the day. Actually, back then I was an `hg` guy. That battle was lost long ago though. I think you linked to the same post as OP, though?
    - stavros 1y ago
      I wrote the post, so that's a post from the perspective of someone who doesn't hate git :P I used bzr after SVN, but my larger point is that it's all fine, the question was whether you want to go through some short-term learning for long-term gain, or if you want to keep using what you know. Either is fine, I'm still using vim as my editor, for example.
wakamoleguy 1y ago
I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh. I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t know what! :-/
- stavros 1y ago
  That's really odd, maybe the tree is somehow messed up? I've never had this problem. What's conflicting? Can you try it on a fresh clone and see if it still happens?
  - wakamoleguy 1y ago
    Maybe it’s based on whether the GitHub merge is a squash, rebase, or plain merge? Or do folks usually manually perform the merge with jj?
    - stavros 1y ago
      It shouldn't matter, under the hood the tree is the same for both. I don't know why jj would complain but git wouldn't, hm.
      - arccy 1y ago
        for me, squash merges are enforced on github, and usually results in some weird / empty commits if i rebase a local stack after pulling in changes with part of the stack merged.
        wakamoleguy 1y ago
        It’s also possible that I start my next task without remembering to create a new diff first. That might explain the conflict when the original commit becomes immutable?
jdmg94 1y ago
"Git is too hard" is never a good argument to promote the use of a different tool. I use git on the terminal exclusively, never had an issue amending a commit or rebasing a branch, or even dealing with conflict resolution most of the time I just use one of the automatic strategies.
- angiolillo 1y ago
  > "Git is too hard" is never a good argument to promote the use of a different tool. Really? Pointing out that a tool is difficult to use seems like an excellent argument to promote the use of a different (supposedly simpler) tool. Specifically in the case of git, I'm glad it was not difficult for you, but it is undeniable that it is a very difficult tool for many people to learn.
manbash 1y ago
Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The guards and rails of git is what makes me feel safe. I am still failing to see why JJ is superior to git, or whatever.
- stavros 1y ago
  If you don't want automatic, you shouldn't use git. It does too many things automatically, like update your branches' heads whenever you commit, for example.
  - 1718627440 1y ago
    And if I don't want that I can detach the HEAD. This isn't to much different. The only thing that changes by using branches is that you have a nice name, it prevents the commits from being GCed and it provides a default name on push.
- killerstorm 1y ago
  Hmm, what guards and rails? There are some convention people follow when working with git to make it safe to use. But those aren't git's features -- they are ways to avoid confusion.
- bdangubic 1y ago
  It's not that it is superior, it is completely inferior to git :) That is why you are failing to see :)
- baq 1y ago
  JJ rebase coupled with committable conflicts is very much superior to git.
ramon156 1y ago
Weird cultish vibes I'm getting, especially the "i just dont get git" part. Shows that you did no research.
drdrey 1y ago
it's hard to take the article seriously when the author relies on a fuckgit alias on a regular basis
- ahartmetz 1y ago
  git rebase|cherry-pick|revert --abort and git reflog can solve pretty much all of my problems with git repos in weird states, and any advanced Git user should know them.
teh64 1y ago
I don't really understand the appeal of jj as someone who uses sublime merge [0]. It has good support for submodules, a lot of the editing commits (messages, squash, move etc...) is really easy and I can also see and edit my stashes directly. Is there any benefit to jj compared to this? [0] https://www.sublimemerge.com/ https://www.sublimemerge.com/
- baq 1y ago
  committable conflicts give you painless rebases. if you know about rerere, try jj; if you don't, it might not be worth it.
conradludgate 1y ago
Until jj supports `git rebase -x "cargo check --deny warnings"`, it's useless to me. jj has primitive support for fixing individual files that changed, but it cannot work on any linter or formatter that depends on other files.
futurecat 1y ago
I have primarily used git in the terminal for more than a decade. I also used magit when I was primarily working in emacs (magit's great!). I now primarily use lazygit. While I'm not a fan of the whole UI, this is the only git tool that makes me go super fast while creating a near-perfect commit history. I tried using jj but immediately stopped after installation as it required a learning curve that I wasn't ready to commit to yet.
- nchmy 1y ago
  you might consider trying again, but do so with jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) - very similar concept to lazygit and makes working with (the already simple) jj even more seamless and intuitive
  - futurecat 1y ago
    thanks!
- wry_discontent 1y ago
  If you use Emacs, there's a mode similar to magit that's under active development: https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el
umvi 1y ago
I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article. Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph. If you use this mental model, suddenly things like git rebase or git reset become far less mysterious and arcane since they are just simple graph operations. Like `git reset --hard X` means "Make current branch's text pointer point to X"
- leipert 1y ago
  Totally agree on the DAG point of view, but I would argue that for different people you need different analogies/models to make it click. I would argue that pointing towards graph theory might help people that have a formal CS or maths education, but not necessarily folks that went through bootcamps, switched from design roles, have a biology background (e.g. bioinformatics) or do statistics (e.g. in medicine or psychology)
- et1337 1y ago
  I think the author is one of those folks who were able to fully grasp the beauty of the Git data model for the first time by switching to Jujutsu. It makes it easier to see the “DAG of commits” vision than Git with its index and stashes and confusingly named commands with fifty flags.
  - Izkata 1y ago
    Which is why I always make sure to show that graph to co-workers new to git (we have a lot of code still on svn): git log --graph --oneline --decorate --all -100 I keep it as an alias, but it is annoying that seeing the whole structure is so hidden away.
    - 1718627440 1y ago
      Isn't this the same graph, that every Git GUI program shows?
a3w 1y ago
I use a gui for 90% of my workflows. Another 9 percent points are hitting back in my console history to rerun commands, never mind if git or jj or POSIX that affect my working dir or index state. What am I supposed to do, use the UI plus jj, and prompt an LLM to use which: git, or jj, in case I am too lazy to think of the right command in the remaining one percent of cases? But in general, I like the "less states and DVCS features than git" approach, but would not switch back to mercurial just to avoid the whole "should we rebase or create merge-commits" discussions in our teams due to having a single default that might not be optimal for everyone, but just works.
- nchmy 1y ago
  use jjui - its an absolute pleasure to use as you dont need to know anything beyond arrow keys and some keyboard shortcuts (which you can also find in the ? help menu). https://github.com/idursun/jjui https://github.com/idursun/jjui If it doesnt do anything you already need, then the maintainer is likely to add it quickly - its rare to find someone so responsive
oxceedo 1y ago
In the past 2 months, I saw 3 articles about JJ. Always the same starting point: "I don't understand how git works". If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope). Abstracting this knowledge by using a tool that does things quite differently won't help you at all on the long run.
- rob74 1y ago
  Ok, I can get behind JFK's quote "We choose to go to the Moon not because it is easy, but because it is hard" - but do we have to apply the same quote to git? The way I see it, git is a tool and not a goal in and of itself. If there is a tool that does the same thing in an easier to use way (and can work with git repos), why use git? Of course, using VCS is part of the job description of almost every developer in the world, but git !== VCS...
- tcoff91 1y ago
  I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools. Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python. https://ofcr.se/jujutsu-merge-workflow/ https://ofcr.se/jujutsu-merge-workflow/
  - umvi 1y ago
    Well then articles should focus on that if they want to convince people who use git as a daily driver. Currently the impression I get from jj is that it's "git for people who have a hard time understanding/using git", therefore since I don't have a hard time understanding/using git, jj is not for me. Maybe more articles showing galaxy brain SCM workflows that are difficult under git but possible under jj and are killer for productivity is a better marketing strategy for jj.
    - 1y ago
karmakaze 1y ago
> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...] > If you don't like Jujutsu, you're wrong It would be much more convincing if they had any idea of git that they were comparing it to.
- stavros 1y ago
  Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point.
  - karmakaze 1y ago
    Fair enough. I'll reconsider if my git workflow is impacted to a point where it shows up to be non-negligible under Amdahl's Law. Edit: read more of the post and I still don't see the big deal. It's like rebase/edit with a bit less typing.
    - baq 1y ago
      ‘A bit less typing’ is the point, it makes a painful workflow into a pleasurable one.
  - eviks 1y ago
    Have you done this in those 20 years? > One day I randomly decided to try again, but this time I asked Claude how to do As this seems to be the reason for having "a great idea" , an alternative explanation
    - stavros 1y ago
      I did, yes, it didn't help.
nchmy 1y ago
one of the better jj writeups. People, just TRY it out.
- deleted 1y ago
  [deleted]
- 1718627440 1y ago
  It needs a newer Rust version than what is available in my packages and figuring out how to properly bootstrap Rust seams like too much work. And no I will not run the equivalent of curl|bash in anyway.
  - nchmy 1y ago
    This might help you manage different versions of different tools https://mise.jdx.dev/ https://mise.jdx.dev/ Mise and jj (and jjui) are my favourite tools, by far.
    - 1718627440 1y ago
      Well the issue I have is that I don't want more than one package manager on my system, and I prefer it to be from the OS, because I already need to trust this by necessity. In my opinion having multiple package managers only complicates the system and causes more problems then it solves. In fact I think the package manager is the OS. I can swap out the kernel and all the userspace with it, but changing the package manager will be disruptive.
cestith 1y ago
The article reads like you can’t change local git history before pushing. I do that all the time.
nchmy 1y ago
what im most impressed by when I read the comments to jj-related threads is how many people are handwriting assembly code. I come to this conclusion because there's always a large amount of people saying "if you dont understand, let alone have mastered, git, then you dont get to have an opinion" So, clearly these people similarly dont use ease-of-use abstractions like programming languages
- legacynl 1y ago
  Alright "touche" my guy, so original as well. > if you dont understand, let alone have mastered, git, then you dont get to have an opinion Eh Yeah kind of? If you use the wooden end of a hammer to try to hammer a nail, you don't get to complain that a hammer is a shitty tool for hammering nails without looking profoundly stupid. And complaining about people complaining about this is just ignorant. Of course people are allowed to have opinions on git (or anything), but if your 2nd sentence is 'i have a command that deletes the .git folder and replaces it with a fresh copy', it shows that maybe the author is still in the hammering nails with the wooden part phase.
  - nchmy 1y ago
    Jj is just simple to use - especially if you use it with jjui. It would never occur to someone to hit the nail with the handle. Conversely, git requires a whole apprenticeship before you can be effective. Moreover, there's MANY git "masters" who are effusive about how they'll never go back to git after switching to jj. If it is just easier and better for beginners and experts, maybe it's just better.
didip 1y ago
I don’t get it. Git is working well enough. Any failure on git workflows is usually failure in team process.
1718627440 1y ago
When checking out means to just "reopen" an older commit, how do you checkout single files in JJ?
- sfink 1y ago
  Depends on what you mean. "Checking out" is ambiguous, and in fact isn't jj terminology. As git terminology, it could mean switching branches or showing file contents or going to a detached HEAD or resetting file contents. If you want the contents of the file at some old commit 0a123, `jj file show -r 0a123 <filename>`. If you want to overwrite the current version of a file with the version from 0a123, `jj restore --from 0a123 <filename>`. How do you "checkout single files" in git? What does that mean?
  - 1718627440 1y ago
    > How do you "checkout single files" in git? What does that mean? git checkout 0a123 -- <filename> So the answer is jj restore. Thanks. Checkout means that the version of some files at some commit is "checked out" in the worktree. So all these things are mostly the same in Git terms. The arbitrary split into switch and restore is confusing to me.
joshheyse 1y ago
In the age of Claude Code and other MCPs, the last thing I want is my commit history to be mutable. I've added instructions to Claude which make a commit before each modification with a summary of the conversation that caused the change. Once I'm happy with the work, I squash the commits and push up. (Which I believe is more or less equivalent to the jj workflow.)
- shaftway 1y ago
  This flow can work with jj also. It would probably be exactly the same. You'd do `jj new` and have Claude set the description and make its changes. When you're ready for the next round, you'd repeat and do `jj new` again for the next revision. I think jj's mutable revisions are best thought of as automation around `git commit --amend && rebase_everything_after_this_commit`. If you're not using that kind of flow with Claude, you wouldn't use that kind of flow with jj either.
karmakaze 1y ago
Anyone using `jj`, how well does it scale? I routinely use .git folders that are 11GB (+4GB checked out files) and 10k+ branches without issue.
- sfink 1y ago
  My data point is the Mozilla monorepo. My .git directory is 5.5GB, so half of what you're talking about. jj speed has not been a problem at all. Some thing are sped up a bit by enabling watchman, but I didn't bother for the first 4 months or so that I used it because the speed was already fine and I didn't want to add another point of failure. (And in fact, when I first enabled it, it slowed things down because the checkout is too big and hit inotify limits.) I don't have very many branches, though. 13 branches, 6838 tags. Some caveats: jj's version of `blame` (jj file annotate) is painfully slow and I usually run `git blame` instead. (Which is a general thing: if anything is missing or slow, you can always just do it with git.) jj's rebase is insanely fast -- especially if you add in the time to manually resolve conflicts, since a good chunk of the time I don't have to spend any time at all since the conflicts are only in experimental twigs that I may never need to go back to (and if I do, it's fine to wait until I need it).
- steveklabnik 1y ago
  jj is being used inside Google with their monorepo. It’s not using the git backend, obviously, but it can scale up to that.
hyperpl 1y ago
I like jj and would just switch over to it but I'm too reliant upon certain workflows fugitive provides. I hope to see a good neovim plugin someday.
tommica 1y ago
Have not finished the article yet, but it's scary how well it's guessing my thoughts and answering my questions/worries. Really well written
tmtvl 1y ago
I appreciate Jujutsu, I mean, the Gracies basically proved its effectiveness to the world, however, combat sports don't suit every temperament. The intensity can also be a bit much for those with weaker constitutions. That said, wrestling predates humanity, so it's definitely worth checking out some variation.
- rkomorn 1y ago
  Personally, I found that while git often made me want to strangle myself, now I have someone else who will happily do it for me. Great transition. Strong recommend.
Mithriil 1y ago
> since its commands were an inscrutable jumble of ill-fitting incantations, and it has remained this way until today What command is he talking about? When you get that git is a graph manager, it gets really easy to manage, very quickly..
- constantcrying 1y ago
  I thought so as well. A long time got seemed quite mysterious, but after I understood what git actually was, it became very coherent and the naming became intuitive. Also, while I think the UI of git can be improved, it is not more complex than it needs to be.
goobert 1y ago
Every time I read about someone's woes with git I have no idea how people run into certain scenarios or what people are even talking about, it reads like "if you've ever tried to unfrobnicate all non-downstream flanges without rebasing your head ref onto the flange upstream of your commit, you'll know this is really hard to do in git", I just think great I have never tried to do that in 20 years of git usage and have no idea what I'd want to, I'm just going to keep using the same ~5 commands and avoiding complexity which has served me well and allowed to avoid any crazy vcs issues that seem to plague other developers
- ItsHarper 1y ago
  That's how I started, but there's big advantages to workflows that are easy to mess up using got, but more natural with jj.
tmcdos 1y ago
Too sad it does not work on Windows 7.
moribvndvs 1y ago
I’ve never had to delete .git and start over so I’m not sure if I’m doing something right or wrong. At any rate, every “jujitsu is so much easier/so much better” post I’ve read thus far has been too lengthy, vague (the mental model you’re selling is “play-doh”? Really?), and hand wavy. As far as using the tool to make it click for myself, it hasn’t. I won’t judge that the tool is good or bad, since clearly I don’t understand it enough to make that call, but the fact that I can just go back to git and be productive as I have been with it for nearly 20 years suggests the value proposition of “switch to jujutsu already” isn’t as high as the evangelists are claiming.

116 points by birdculture 1y ago

I have been trying Jujutsu for a few weeks. It's cool and I like trying new things. I wouldn't say that it's so much better than git, though; there is nothing that I miss in the projects where I use git. On the other hand, I have issues with Jujutsu, one of which completely prevents me from using it in some projects: * No support for git submodules. One can dislike submodules as much as they want, if I need to contribute to a repository using them, I can't use Jujutsu. * The signing support is very annoying with a security key. Even if I configure 'sign-on-push', it will access the security key every time it tries to check the signature, which is pretty much every `jj st` or `jj log` after something has changed locally. I don't need to check my own signatures, IMO they should be checked on fetch and on push. * There is no way to configure a 'defaultKeyCommand' like in git, which I now rely on (because I have multiple security keys).

stavros 1y ago
Yeah, it sounds like you have specific requirements that don't let you use jj until it gets support for those. That's fair.
ahartmetz 1y ago
I also have that problem with submodules. Of course they are crap, but the project uses them.

itchynosedev 1y ago

I really loved jujutsu for the few weeks that I used it. However, I did find all my tools that rely on Git (eg Gitlab CLI that can open merge request from the current branch) breaking because JJ operations result in detached head in Git. In addition, mixing Git and JJ will result in your repos becoming really slow when you do need to run some Git operation.

stavros 1y ago
Hm, I can't speak to the tools, I imagine you're right. I haven't found any slowness, though. Why would jj slow git down?
- 1718627440 1y ago
  I also use them, because I don't know a better alternative. I want it the subproject's version to be defined in a parent's commit and also modify the subproject. Changes to the subproject should stay in the commit history of the subproject Is there a better way?
- itchynosedev 1y ago
  I noticed some of my hybrid repositories were slow on regular git commands (eg log) and running garbage collection manual resolved it. Perhaps, jj created a lot of unreachable objects?
  - 1718627440 1y ago
    JJ invites rebase heavy workflows and since it uses git, commits are still immutable, so it needs to create new commits. So this sounds quite expected.
ljm 1y ago
One of the bigger selling points of JJ just wouldn't work so well without larger team buy in for me: the ability to push stacked PRs. I like the idea of it, but there's so much inertia around typical git workflows that revolve around the GH pull request model (with the only difference being the use of trunk based dev or some git-flow like branching strategy) that it'd be hard to change without a lot of buy in. I still think back to Phabricator and its approach to code review, noting that it sadly never got wider traction despite having notable benefits over a completely entrenched status quo.

roxolotl 1y ago

> Jujutsu, in contrast, is more like playing with Play-Doh. You take a lump, cut it into two, shape one piece into something, give it a name, change your mind, give it another name, take a bit of the second piece and stick it on the first piece, and generally go back and forth all around your play area, making changes. I love this description and it describes how I work with git. When I’m doing things locally I’m constantly committing small wip commits. When I get something the way I like it I’ll interactive rebase/just back it all up, and then create the perfect little boxes. I guess I should try jujutsu since it sounds like it might be even more for me. Although if you can’t get to the perfect boxes at the end I don’t know if I’d like it.

stavros 1y ago
I'll say that Jujutsu makes the way to get to the perfect boxes really friction-free.
simgt 1y ago
That's how I feel like working with git locally using a combination of basic commands and gitup (https://gitup.co/ https://gitup.co/), that may be why I couldn't really get the selling point of jj when I tried it a couple weeks ago. The only part that piqued my interest is merges being always successful and conflicts just sitting in the tree, waiting patiently to be resolved... It's the next logical step after being able to commit without synchronizing when we all moved away from SVN.
- 1718627440 1y ago
  > gitup (https://gitup.co/ https://gitup.co/) That looks actually nice, but it seams to require macOS.
nchmy 1y ago
I think you would love jj then. It is dead-simple to just move things around - branches/bookmarks, commits and even single lines of code within a diff. jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) makes it all that much easier too

jakebasile 1y ago

I just don't have enough pain points with Git to move to something new. I don't have a problem remembering the ~5 commands I need most on any given workday. Between stashes, branches, temporary commits I later rebase, and recently worktrees, I don't lack for anything in my usage. It's universally used across both my public and corporate life, and neither does anyone need to learn a new tool to interact with my code base, nor do I need to deal with possible inconsistencies by using a different frontend on my end. It's cool that it exists, and it's impressive that it is built on top of git itself. If you (like the author) want to use it, then more power to you. But I have yet to be convinced by any of these articles that it is worth my time to try it since nearly all of them start from a point of "if you hate Git like me, then try this thing". If anyone has a link to an article written from the point of view of "I love or at least tolerate git and have no real issues with it, here's why I like JJ," then I'd be glad to read it.

stavros 1y ago
I don't hate git, I like it fine and, until recently, used it exclusively on all my projects (I still use it non-exclusively). Here's an article that's written from that viewpoint: https://www.stavros.io/posts/switch-to-jujutsu-already-a-tutorial/ https://www.stavros.io/posts/switch-to-jujutsu-already-a-tut... That having been said, I didn't hate Subversion either. It was fine.
- jakebasile 1y ago
  Yeah I definitely hated Subversion, which helped push me to try Git back in the day. Actually, back then I was an `hg` guy. That battle was lost long ago though. I think you linked to the same post as OP, though?
  - stavros 1y ago
    I wrote the post, so that's a post from the perspective of someone who doesn't hate git :P I used bzr after SVN, but my larger point is that it's all fine, the question was whether you want to go through some short-term learning for long-term gain, or if you want to keep using what you know. Either is fine, I'm still using vim as my editor, for example.

wakamoleguy 1y ago

I have been trying to use jj for a couple months now, but hitting some friction with my company’s GitHub PR workflow. Specifically, after the PR is merged, the next time I fetch I always end up with a ton of conflicts. It gets hard to clean them up, so I often end up abandoning all mutable commits to start fresh. I feel like I’m doing something wrong, as I haven’t seen this mentioned in any tutorials, but I don’t know what! :-/

stavros 1y ago
That's really odd, maybe the tree is somehow messed up? I've never had this problem. What's conflicting? Can you try it on a fresh clone and see if it still happens?
- wakamoleguy 1y ago
  Maybe it’s based on whether the GitHub merge is a squash, rebase, or plain merge? Or do folks usually manually perform the merge with jj?
  - stavros 1y ago
    It shouldn't matter, under the hood the tree is the same for both. I don't know why jj would complain but git wouldn't, hm.
    - arccy 1y ago
      for me, squash merges are enforced on github, and usually results in some weird / empty commits if i rebase a local stack after pulling in changes with part of the stack merged.
      - wakamoleguy 1y ago
        It’s also possible that I start my next task without remembering to create a new diff first. That might explain the conflict when the original commit becomes immutable?

jdmg94 1y ago

"Git is too hard" is never a good argument to promote the use of a different tool. I use git on the terminal exclusively, never had an issue amending a commit or rebasing a branch, or even dealing with conflict resolution most of the time I just use one of the automatic strategies.

angiolillo 1y ago
> "Git is too hard" is never a good argument to promote the use of a different tool. Really? Pointing out that a tool is difficult to use seems like an excellent argument to promote the use of a different (supposedly simpler) tool. Specifically in the case of git, I'm glad it was not difficult for you, but it is undeniable that it is a very difficult tool for many people to learn.

manbash 1y ago

Right in the first paragraph. > Needless to say, I just don’t get git. What is there not to _get_, honestly? And why is jj so easier to get? The author seems to focus on how great it is to make changes to your commit history locally, and that you shouldn't worry because it's not pushed yet. The thing is, I don't want automatic. Automatic sucks. The point of version control is that I am able to curate my changes. The guards and rails of git is what makes me feel safe. I am still failing to see why JJ is superior to git, or whatever.

stavros 1y ago
If you don't want automatic, you shouldn't use git. It does too many things automatically, like update your branches' heads whenever you commit, for example.
- 1718627440 1y ago
  And if I don't want that I can detach the HEAD. This isn't to much different. The only thing that changes by using branches is that you have a nice name, it prevents the commits from being GCed and it provides a default name on push.
killerstorm 1y ago
Hmm, what guards and rails? There are some convention people follow when working with git to make it safe to use. But those aren't git's features -- they are ways to avoid confusion.
bdangubic 1y ago
It's not that it is superior, it is completely inferior to git :) That is why you are failing to see :)
baq 1y ago
JJ rebase coupled with committable conflicts is very much superior to git.

ramon156 1y ago

Weird cultish vibes I'm getting, especially the "i just dont get git" part. Shows that you did no research.

drdrey 1y ago

it's hard to take the article seriously when the author relies on a fuckgit alias on a regular basis

ahartmetz 1y ago
git rebase|cherry-pick|revert --abort and git reflog can solve pretty much all of my problems with git repos in weird states, and any advanced Git user should know them.

teh64 1y ago

I don't really understand the appeal of jj as someone who uses sublime merge [0]. It has good support for submodules, a lot of the editing commits (messages, squash, move etc...) is really easy and I can also see and edit my stashes directly. Is there any benefit to jj compared to this? [0] https://www.sublimemerge.com/ https://www.sublimemerge.com/

baq 1y ago
committable conflicts give you painless rebases. if you know about rerere, try jj; if you don't, it might not be worth it.

conradludgate 1y ago

Until jj supports `git rebase -x "cargo check --deny warnings"`, it's useless to me. jj has primitive support for fixing individual files that changed, but it cannot work on any linter or formatter that depends on other files.

futurecat 1y ago

I have primarily used git in the terminal for more than a decade. I also used magit when I was primarily working in emacs (magit's great!). I now primarily use lazygit. While I'm not a fan of the whole UI, this is the only git tool that makes me go super fast while creating a near-perfect commit history. I tried using jj but immediately stopped after installation as it required a learning curve that I wasn't ready to commit to yet.

nchmy 1y ago
you might consider trying again, but do so with jjui (https://github.com/idursun/jjui https://github.com/idursun/jjui) - very similar concept to lazygit and makes working with (the already simple) jj even more seamless and intuitive
- futurecat 1y ago
  thanks!
wry_discontent 1y ago
If you use Emacs, there's a mode similar to magit that's under active development: https://github.com/bolivier/jj-mode.el https://github.com/bolivier/jj-mode.el

umvi 1y ago

I feel like anyone who spends just a couple of hours learning git will have a much better mental model than the crappy "Assembly line" model from the article. Your real mental model of git should be an acyclic directed graph where the nodes are commits and the edges are ancestry. Commits represents snapshot of the project's state. Tags and branches are just text pointers to commits in the graph. If you use this mental model, suddenly things like git rebase or git reset become far less mysterious and arcane since they are just simple graph operations. Like `git reset --hard X` means "Make current branch's text pointer point to X"

leipert 1y ago
Totally agree on the DAG point of view, but I would argue that for different people you need different analogies/models to make it click. I would argue that pointing towards graph theory might help people that have a formal CS or maths education, but not necessarily folks that went through bootcamps, switched from design roles, have a biology background (e.g. bioinformatics) or do statistics (e.g. in medicine or psychology)
et1337 1y ago
I think the author is one of those folks who were able to fully grasp the beauty of the Git data model for the first time by switching to Jujutsu. It makes it easier to see the “DAG of commits” vision than Git with its index and stashes and confusingly named commands with fifty flags.
- Izkata 1y ago
  Which is why I always make sure to show that graph to co-workers new to git (we have a lot of code still on svn): git log --graph --oneline --decorate --all -100 I keep it as an alias, but it is annoying that seeing the whole structure is so hidden away.
  - 1718627440 1y ago
    Isn't this the same graph, that every Git GUI program shows?

a3w 1y ago

I use a gui for 90% of my workflows. Another 9 percent points are hitting back in my console history to rerun commands, never mind if git or jj or POSIX that affect my working dir or index state. What am I supposed to do, use the UI plus jj, and prompt an LLM to use which: git, or jj, in case I am too lazy to think of the right command in the remaining one percent of cases? But in general, I like the "less states and DVCS features than git" approach, but would not switch back to mercurial just to avoid the whole "should we rebase or create merge-commits" discussions in our teams due to having a single default that might not be optimal for everyone, but just works.

nchmy 1y ago
use jjui - its an absolute pleasure to use as you dont need to know anything beyond arrow keys and some keyboard shortcuts (which you can also find in the ? help menu). https://github.com/idursun/jjui https://github.com/idursun/jjui If it doesnt do anything you already need, then the maintainer is likely to add it quickly - its rare to find someone so responsive

oxceedo 1y ago

In the past 2 months, I saw 3 articles about JJ. Always the same starting point: "I don't understand how git works". If you can't understand git, one of the most used tool in the whole industry, this is a *you* problem. You MUST take the time to understand how it works properly. Every job you'll get and every projects you'll work on will use a Version Control (at least I hope). Abstracting this knowledge by using a tool that does things quite differently won't help you at all on the long run.

rob74 1y ago
Ok, I can get behind JFK's quote "We choose to go to the Moon not because it is easy, but because it is hard" - but do we have to apply the same quote to git? The way I see it, git is a tool and not a goal in and of itself. If there is a tool that does the same thing in an easier to use way (and can work with git repos), why use git? Of course, using VCS is part of the job description of almost every developer in the world, but git !== VCS...
tcoff91 1y ago
I am a git expert and I very much prefer jj. It enables workflows that are impractical with git. It’s hard to even imagine these workflows if you only use git because your thinking is constrained by the limitations of your tools. Git rebase is like programming with punch cards compared to jj’s rebase being like writing Python. https://ofcr.se/jujutsu-merge-workflow/ https://ofcr.se/jujutsu-merge-workflow/
- umvi 1y ago
  Well then articles should focus on that if they want to convince people who use git as a daily driver. Currently the impression I get from jj is that it's "git for people who have a hard time understanding/using git", therefore since I don't have a hard time understanding/using git, jj is not for me. Maybe more articles showing galaxy brain SCM workflows that are difficult under git but possible under jj and are killer for productivity is a better marketing strategy for jj.
  - 1y ago

karmakaze 1y ago

> Needless to say, I just don’t get git. I never got it, even though I’ve read a bunch of stuff on how it represents things internally. I’ve been using it for years knowing what a few commands do, and [...] > If you don't like Jujutsu, you're wrong It would be much more convincing if they had any idea of git that they were comparing it to.

stavros 1y ago
Except, the fact that I have no idea of git after 20 years of use, whereas I have a great idea of jj after two months is exactly the point.
- karmakaze 1y ago
  Fair enough. I'll reconsider if my git workflow is impacted to a point where it shows up to be non-negligible under Amdahl's Law. Edit: read more of the post and I still don't see the big deal. It's like rebase/edit with a bit less typing.
  - baq 1y ago
    ‘A bit less typing’ is the point, it makes a painful workflow into a pleasurable one.
- eviks 1y ago
  Have you done this in those 20 years? > One day I randomly decided to try again, but this time I asked Claude how to do As this seems to be the reason for having "a great idea" , an alternative explanation
  - stavros 1y ago
    I did, yes, it didn't help.

nchmy 1y ago

one of the better jj writeups. People, just TRY it out.

deleted 1y ago
[deleted]
1718627440 1y ago
It needs a newer Rust version than what is available in my packages and figuring out how to properly bootstrap Rust seams like too much work. And no I will not run the equivalent of curl|bash in anyway.
- nchmy 1y ago
  This might help you manage different versions of different tools https://mise.jdx.dev/ https://mise.jdx.dev/ Mise and jj (and jjui) are my favourite tools, by far.
  - 1718627440 1y ago
    Well the issue I have is that I don't want more than one package manager on my system, and I prefer it to be from the OS, because I already need to trust this by necessity. In my opinion having multiple package managers only complicates the system and causes more problems then it solves. In fact I think the package manager is the OS. I can swap out the kernel and all the userspace with it, but changing the package manager will be disruptive.

cestith 1y ago

The article reads like you can’t change local git history before pushing. I do that all the time.

nchmy 1y ago

what im most impressed by when I read the comments to jj-related threads is how many people are handwriting assembly code. I come to this conclusion because there's always a large amount of people saying "if you dont understand, let alone have mastered, git, then you dont get to have an opinion" So, clearly these people similarly dont use ease-of-use abstractions like programming languages

legacynl 1y ago
Alright "touche" my guy, so original as well. > if you dont understand, let alone have mastered, git, then you dont get to have an opinion Eh Yeah kind of? If you use the wooden end of a hammer to try to hammer a nail, you don't get to complain that a hammer is a shitty tool for hammering nails without looking profoundly stupid. And complaining about people complaining about this is just ignorant. Of course people are allowed to have opinions on git (or anything), but if your 2nd sentence is 'i have a command that deletes the .git folder and replaces it with a fresh copy', it shows that maybe the author is still in the hammering nails with the wooden part phase.
- nchmy 1y ago
  Jj is just simple to use - especially if you use it with jjui. It would never occur to someone to hit the nail with the handle. Conversely, git requires a whole apprenticeship before you can be effective. Moreover, there's MANY git "masters" who are effusive about how they'll never go back to git after switching to jj. If it is just easier and better for beginners and experts, maybe it's just better.

didip 1y ago

I don’t get it. Git is working well enough. Any failure on git workflows is usually failure in team process.

1718627440 1y ago

When checking out means to just "reopen" an older commit, how do you checkout single files in JJ?

sfink 1y ago
Depends on what you mean. "Checking out" is ambiguous, and in fact isn't jj terminology. As git terminology, it could mean switching branches or showing file contents or going to a detached HEAD or resetting file contents. If you want the contents of the file at some old commit 0a123, `jj file show -r 0a123 <filename>`. If you want to overwrite the current version of a file with the version from 0a123, `jj restore --from 0a123 <filename>`. How do you "checkout single files" in git? What does that mean?
- 1718627440 1y ago
  > How do you "checkout single files" in git? What does that mean? git checkout 0a123 -- <filename> So the answer is jj restore. Thanks. Checkout means that the version of some files at some commit is "checked out" in the worktree. So all these things are mostly the same in Git terms. The arbitrary split into switch and restore is confusing to me.

joshheyse 1y ago

In the age of Claude Code and other MCPs, the last thing I want is my commit history to be mutable. I've added instructions to Claude which make a commit before each modification with a summary of the conversation that caused the change. Once I'm happy with the work, I squash the commits and push up. (Which I believe is more or less equivalent to the jj workflow.)

shaftway 1y ago
This flow can work with jj also. It would probably be exactly the same. You'd do `jj new` and have Claude set the description and make its changes. When you're ready for the next round, you'd repeat and do `jj new` again for the next revision. I think jj's mutable revisions are best thought of as automation around `git commit --amend && rebase_everything_after_this_commit`. If you're not using that kind of flow with Claude, you wouldn't use that kind of flow with jj either.

karmakaze 1y ago

Anyone using `jj`, how well does it scale? I routinely use .git folders that are 11GB (+4GB checked out files) and 10k+ branches without issue.

sfink 1y ago
My data point is the Mozilla monorepo. My .git directory is 5.5GB, so half of what you're talking about. jj speed has not been a problem at all. Some thing are sped up a bit by enabling watchman, but I didn't bother for the first 4 months or so that I used it because the speed was already fine and I didn't want to add another point of failure. (And in fact, when I first enabled it, it slowed things down because the checkout is too big and hit inotify limits.) I don't have very many branches, though. 13 branches, 6838 tags. Some caveats: jj's version of `blame` (jj file annotate) is painfully slow and I usually run `git blame` instead. (Which is a general thing: if anything is missing or slow, you can always just do it with git.) jj's rebase is insanely fast -- especially if you add in the time to manually resolve conflicts, since a good chunk of the time I don't have to spend any time at all since the conflicts are only in experimental twigs that I may never need to go back to (and if I do, it's fine to wait until I need it).
steveklabnik 1y ago
jj is being used inside Google with their monorepo. It’s not using the git backend, obviously, but it can scale up to that.

hyperpl 1y ago

I like jj and would just switch over to it but I'm too reliant upon certain workflows fugitive provides. I hope to see a good neovim plugin someday.

tommica 1y ago

Have not finished the article yet, but it's scary how well it's guessing my thoughts and answering my questions/worries. Really well written

tmtvl 1y ago

I appreciate Jujutsu, I mean, the Gracies basically proved its effectiveness to the world, however, combat sports don't suit every temperament. The intensity can also be a bit much for those with weaker constitutions. That said, wrestling predates humanity, so it's definitely worth checking out some variation.

rkomorn 1y ago
Personally, I found that while git often made me want to strangle myself, now I have someone else who will happily do it for me. Great transition. Strong recommend.

Mithriil 1y ago

> since its commands were an inscrutable jumble of ill-fitting incantations, and it has remained this way until today What command is he talking about? When you get that git is a graph manager, it gets really easy to manage, very quickly..

constantcrying 1y ago
I thought so as well. A long time got seemed quite mysterious, but after I understood what git actually was, it became very coherent and the naming became intuitive. Also, while I think the UI of git can be improved, it is not more complex than it needs to be.

goobert 1y ago

Every time I read about someone's woes with git I have no idea how people run into certain scenarios or what people are even talking about, it reads like "if you've ever tried to unfrobnicate all non-downstream flanges without rebasing your head ref onto the flange upstream of your commit, you'll know this is really hard to do in git", I just think great I have never tried to do that in 20 years of git usage and have no idea what I'd want to, I'm just going to keep using the same ~5 commands and avoiding complexity which has served me well and allowed to avoid any crazy vcs issues that seem to plague other developers

ItsHarper 1y ago
That's how I started, but there's big advantages to workflows that are easy to mess up using got, but more natural with jj.

tmcdos 1y ago

Too sad it does not work on Windows 7.

moribvndvs 1y ago

I’ve never had to delete .git and start over so I’m not sure if I’m doing something right or wrong. At any rate, every “jujitsu is so much easier/so much better” post I’ve read thus far has been too lengthy, vague (the mental model you’re selling is “play-doh”? Really?), and hand wavy. As far as using the tool to make it click for myself, it hasn’t. I won’t judge that the tool is good or bad, since clearly I don’t understand it enough to make that call, but the fact that I can just go back to git and be productive as I have been with it for nearly 20 years suggests the value proposition of “switch to jujutsu already” isn’t as high as the evangelists are claiming.