9 ms·

> Jujutsu is more powerful than Git. Despite the fact that it's easier to learn and more intuitive, it actually has loads of awesome capabilities for power user

> Jujutsu is more powerful than Git. Despite the fact that it's easier to learn and more intuitive, it actually has loads of awesome capabilities for power users that completely leave Git in the dust. Like? This isn't explained, I'm curious on why I would want to use it, but this is just an empty platitude, doesn't really give me a reason to try.

jennyholzer 1y ago
I agree. I'm willing to give them the benefit of the doubt to some extent because existing Git UIs are pretty poor in my opinion. But I'd like to see some more meat on the bone, in particular a demonstration of why this is easier/more powerful/more convenient to use than the alternatives.
- tcoff91 1y ago
  The main thing that makes it more powerful imo is that you can accomplish insane rebases with 1 command that would be really difficult with git. Like let’s say you have 4 separate PRs in review that have no dependency on each other. You then work on new stuff on top of an octopus merge of all 4. You are exploring different approaches to a solution so you have several anonymous branches where you have tried different things. You want to rebase on master, so you just run jj rebase -d master. All 4 PR branches, the octopus merge, the anonymous branches, they all get rebased with that 1 command. If there are conflicts the first class conflicts mean that you can fix the conflicts whenever you want. If one of your experimental anonymous branches is in conflict but you are unlikely to go with that approach, just leave it in a conflicted state unless you change your mind that you want to actually go that direction.
kyrra 1y ago
One example: Merge conflicts can be submitted as a proper entry and dealt with later: https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/
senekor 1y ago
Hi, author here. Since the target audience is people with little to no Git experience, a detailed comparison would not make sense. I did simply make that claim because the weirdness of Git's UI is usually justified by saying how powerful it is. So this statement is just intended to ease the readers mind that they're not missing out on power by choosing a tool that's easier to learn.
- jennyholzer 1y ago
  I appreciate this perspective. IMO, the authors and evangelists of Git are essentially correct when they argue about its power. However, I think that it's extremely difficult to gain practical experience with using Git in a high-powered, high-agency way, mostly because there are a lot of abstract concepts at play and there is no easily accessible place where these concepts can be "discovered". Basically, Git is as good as it's cracked up to be, but only if you're an expert. If you're interested in becoming a Git expert, I cannot recommend Emacs Magit strongly enough. If not, I think Jujutsu could be an quicker road to a high-agency version control workflow. It's at least worth considering. I feel confident that Jujutsu can succeed, in particular because of Git's harsh difficulty curve.
  - senekor 1y ago
    Thanks, but I consider myself a Git expert already :-) I read the Pro Git book cover to cover. I have a gluten-free, artisanal, free-range git config that I've grown and cared for over years. single character aliases all the important commands, "log all graph oneline", "commit amend no-edit", interactive rebase (ofc. with autosquash, autostash, updaterefs and rebasemerges), reset hard, push force-with-lease... Also: commit signing, url rewriting, conditional configs for different orgs, all that jazz. I was super productive with it and loved it. And then Jujutsu came along and casually doubled my VCS productivity. I didn't see it coming!
    - nocman 1y ago
      Is there a particular pain point (or set of pain points) that you have using git which is removed when you use Jujutsu? I am interested to know, because there seem to be a small number of people who really seem to like it, and up to this point I haven't been able to understand what it is that they are all so excited about.
pkulak 1y ago
Say you start on Main, then make a new branch that you intend to be a PR someday. You make commit 1. Then another. Maybe 6 more. Now you realize that something in commit 1 should have been done differently. So, you "edit" commit 1. All the other commits automatically rebase on top and when you go back to your last commit, it's there. Same with _after_ you PR and someone notices something in commit 3. Edit it, push, and it's fixed. You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.
- lrobinovitch 1y ago
  You have to force push each time you do this, right? How do your coworkers find the incremental change you made to commit 1 after you force push it, and how do you deal with collaborative branches effectively this way? And if I don't want to work this way and force push, are there other benefits of jj?
  - baq 1y ago
    the heuristic is 'if you know about rerere and especially if you use it, you should try jj'. if you never force push, you might not see value in jj. (I basically always force push.)
    - lrobinovitch 1y ago
      That makes sense, good to know, thanks. > I basically always force push How do your colleagues deal with this, or is this mostly on experimental branches or individual projects?
      - whateveracct 1y ago
        People barely ever work off my branches.
      - smw 1y ago
        It's generally fine if you force push a branch that you're the only one working on. In many projects, there's an expectation that the 'PR Branch' you create in order to make a github pull request is owned by you, and can be rebased/edited/force-pushed at will. It's very common to do things like `git commit --amend --no-edit` to fix a typo or lint issue and then force push to update the last commit. This has it's problems, and there's a reason things like Geritt are popular in some more sophisticated shops, as they make it much easier to review changes to PRs in response to reviews, as an example.
interroboink 1y ago
Jujutsu has many Mercurial-style features, one of them being revsets[1] - a set-notation-style DSL for selecting changesets (eg: which ones to log, etc). I have never found anything as powerful as revsets in Git.[2] [1] https://jj-vcs.github.io/jj/latest/revsets/ https://jj-vcs.github.io/jj/latest/revsets/ [2] https://stackoverflow.com/questions/22520751/what-is-the-git-equivalent-of-mercurial-revsets https://stackoverflow.com/questions/22520751/what-is-the-git...
- capitainenemo 1y ago
  Yeah, I'm excited by the mercurial-style features as a mercurial user looking for something to transition to in a world where git has, sadly, become the standard. The revsets were definitely a joy to discover. The main thing I'm hoping they add is mercurial's diff format which, according to the jujutsu dev discussions, is considerably better than git's, and allows for cleaner "absorb" and, apparently, the clearness of mercurial's "hg fa --deleted". And, well, it's silly, but I do like revnums. It's a compact way to compare changes over time, even if it's only useful for the local repo. Would be nice to have those too.
- exclipy 1y ago
  git-branchless implements revsets for git https://github.com/arxanas/git-branchless/wiki/Reference:-Revsets https://github.com/arxanas/git-branchless/wiki/Reference:-Re...
  - MrJohz 1y ago
    Git branchless is basically jj as a git subcommand - it's no coincidence that arxanas is also involved in jj's development!
aniviacat 1y ago
It's also quickly followed by: > Jujutsu is relatively new and doesn't cover 100% of the features of Git yet. So it's more powerful except when it's not.
mamcx 1y ago
Other do a lot of nitpicking in workflows (with responses that are expected, like "but who cares" or "in git I could do the same"), but not answer this: JJ is MORE powerful than git because has a BETTER SEMANTICS & ABSTRACTION. That its. Is like when git emerge, it was more powerful than svn because was distributed. I wanna make the point clear: Is NOT about the "amount of features or specific workflows" that with pain can be made on git and with effort could be retrofitted on jj eventually (if today are missed, like a equivalent of GitHub!). The power is what abstraction made jj that is different to git: We work on "commits" all the time, and not need to manually sync the state. Everything derive from this. And because is a better abstraction, it make more sense and is easier to understand. The UX derive from this.

jennyholzer 1y ago

I agree. I'm willing to give them the benefit of the doubt to some extent because existing Git UIs are pretty poor in my opinion. But I'd like to see some more meat on the bone, in particular a demonstration of why this is easier/more powerful/more convenient to use than the alternatives.

tcoff91 1y ago
The main thing that makes it more powerful imo is that you can accomplish insane rebases with 1 command that would be really difficult with git. Like let’s say you have 4 separate PRs in review that have no dependency on each other. You then work on new stuff on top of an octopus merge of all 4. You are exploring different approaches to a solution so you have several anonymous branches where you have tried different things. You want to rebase on master, so you just run jj rebase -d master. All 4 PR branches, the octopus merge, the anonymous branches, they all get rebased with that 1 command. If there are conflicts the first class conflicts mean that you can fix the conflicts whenever you want. If one of your experimental anonymous branches is in conflict but you are unlikely to go with that approach, just leave it in a conflicted state unless you change your mind that you want to actually go that direction.

kyrra 1y ago

One example: Merge conflicts can be submitted as a proper entry and dealt with later: https://jj-vcs.github.io/jj/latest/conflicts/ https://jj-vcs.github.io/jj/latest/conflicts/

senekor 1y ago

Hi, author here. Since the target audience is people with little to no Git experience, a detailed comparison would not make sense. I did simply make that claim because the weirdness of Git's UI is usually justified by saying how powerful it is. So this statement is just intended to ease the readers mind that they're not missing out on power by choosing a tool that's easier to learn.

jennyholzer 1y ago
I appreciate this perspective. IMO, the authors and evangelists of Git are essentially correct when they argue about its power. However, I think that it's extremely difficult to gain practical experience with using Git in a high-powered, high-agency way, mostly because there are a lot of abstract concepts at play and there is no easily accessible place where these concepts can be "discovered". Basically, Git is as good as it's cracked up to be, but only if you're an expert. If you're interested in becoming a Git expert, I cannot recommend Emacs Magit strongly enough. If not, I think Jujutsu could be an quicker road to a high-agency version control workflow. It's at least worth considering. I feel confident that Jujutsu can succeed, in particular because of Git's harsh difficulty curve.
- senekor 1y ago
  Thanks, but I consider myself a Git expert already :-) I read the Pro Git book cover to cover. I have a gluten-free, artisanal, free-range git config that I've grown and cared for over years. single character aliases all the important commands, "log all graph oneline", "commit amend no-edit", interactive rebase (ofc. with autosquash, autostash, updaterefs and rebasemerges), reset hard, push force-with-lease... Also: commit signing, url rewriting, conditional configs for different orgs, all that jazz. I was super productive with it and loved it. And then Jujutsu came along and casually doubled my VCS productivity. I didn't see it coming!
  - nocman 1y ago
    Is there a particular pain point (or set of pain points) that you have using git which is removed when you use Jujutsu? I am interested to know, because there seem to be a small number of people who really seem to like it, and up to this point I haven't been able to understand what it is that they are all so excited about.

pkulak 1y ago

Say you start on Main, then make a new branch that you intend to be a PR someday. You make commit 1. Then another. Maybe 6 more. Now you realize that something in commit 1 should have been done differently. So, you "edit" commit 1. All the other commits automatically rebase on top and when you go back to your last commit, it's there. Same with _after_ you PR and someone notices something in commit 3. Edit it, push, and it's fixed. You can do all that in Git, but I sure as hell never did; and my co-workers really appreciate PRs that are broken into lots of little commits that can be easily looked over, one by one.

lrobinovitch 1y ago
You have to force push each time you do this, right? How do your coworkers find the incremental change you made to commit 1 after you force push it, and how do you deal with collaborative branches effectively this way? And if I don't want to work this way and force push, are there other benefits of jj?
- baq 1y ago
  the heuristic is 'if you know about rerere and especially if you use it, you should try jj'. if you never force push, you might not see value in jj. (I basically always force push.)
  - lrobinovitch 1y ago
    That makes sense, good to know, thanks. > I basically always force push How do your colleagues deal with this, or is this mostly on experimental branches or individual projects?
    - whateveracct 1y ago
      People barely ever work off my branches.
    - smw 1y ago
      It's generally fine if you force push a branch that you're the only one working on. In many projects, there's an expectation that the 'PR Branch' you create in order to make a github pull request is owned by you, and can be rebased/edited/force-pushed at will. It's very common to do things like `git commit --amend --no-edit` to fix a typo or lint issue and then force push to update the last commit. This has it's problems, and there's a reason things like Geritt are popular in some more sophisticated shops, as they make it much easier to review changes to PRs in response to reviews, as an example.

interroboink 1y ago

Jujutsu has many Mercurial-style features, one of them being revsets[1] - a set-notation-style DSL for selecting changesets (eg: which ones to log, etc). I have never found anything as powerful as revsets in Git.[2] [1] https://jj-vcs.github.io/jj/latest/revsets/ https://jj-vcs.github.io/jj/latest/revsets/ [2] https://stackoverflow.com/questions/22520751/what-is-the-git-equivalent-of-mercurial-revsets https://stackoverflow.com/questions/22520751/what-is-the-git...

capitainenemo 1y ago
Yeah, I'm excited by the mercurial-style features as a mercurial user looking for something to transition to in a world where git has, sadly, become the standard. The revsets were definitely a joy to discover. The main thing I'm hoping they add is mercurial's diff format which, according to the jujutsu dev discussions, is considerably better than git's, and allows for cleaner "absorb" and, apparently, the clearness of mercurial's "hg fa --deleted". And, well, it's silly, but I do like revnums. It's a compact way to compare changes over time, even if it's only useful for the local repo. Would be nice to have those too.
exclipy 1y ago
git-branchless implements revsets for git https://github.com/arxanas/git-branchless/wiki/Reference:-Revsets https://github.com/arxanas/git-branchless/wiki/Reference:-Re...
- MrJohz 1y ago
  Git branchless is basically jj as a git subcommand - it's no coincidence that arxanas is also involved in jj's development!

aniviacat 1y ago

It's also quickly followed by: > Jujutsu is relatively new and doesn't cover 100% of the features of Git yet. So it's more powerful except when it's not.

mamcx 1y ago

Other do a lot of nitpicking in workflows (with responses that are expected, like "but who cares" or "in git I could do the same"), but not answer this: JJ is MORE powerful than git because has a BETTER SEMANTICS & ABSTRACTION. That its. Is like when git emerge, it was more powerful than svn because was distributed. I wanna make the point clear: Is NOT about the "amount of features or specific workflows" that with pain can be made on git and with effort could be retrofitted on jj eventually (if today are missed, like a equivalent of GitHub!). The power is what abstraction made jj that is different to git: We work on "commits" all the time, and not need to manually sync the state. Everything derive from this. And because is a better abstraction, it make more sense and is easier to understand. The UX derive from this.