8 ms·

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3.

I'm still unsure of why I'd want to move to jj from git. My ideal git workflow is pretty simple: 1. `git switch -C new-branch` 2. Make changes, time passes 3. `git add .` 4. `git commit -m "Description of changes made"` 5. `git fetch && git rebase origin/main` 6. `git push` 7. Make pr to main If main is out of date I rebase again to update. This to me feels pretty light weight and is not a hinderence in any way on my day to day tasks. What exactly makes `jj` better? Is there a specific usecase i'm not understanding?

lawn 2y ago
One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.
- ocular-rockular 2y ago
  But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicated to need a solution to problems I don't have?
  - lawn 2y ago
    It's not the only improvement though, depending on your workflow. Another thing you can do is work on multiple branches at the same time. See: https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
  - keybored 2y ago
    It’s not necessarily the only use case. But as I’ve read (according to Martin) doing it this way simplifies the implementation a lot. You track everything directly in the DB. In turn you don’t have to care about all sorts of states like being in conflicted git-am state, conflicted git-merge, etc.—these states cannot happen, it’s all in the DB (not some dirty working tree state where some flags or files somewhere in `.git` or `.jj` tell you “there are some conflict markers thereabouts, enjoy”). And that frames it in terms of being easier for the people implementing jj. But I think it will also benefit us users by making it easier for them to create streamlined tools. git-rebase(1) and all that is great and all. But definitely messy. And we only recently got `--update-refs` to update dependent branches, which is kind of late considering how important branches are in Git.
  - zug_zug 2y ago
    Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once (to everyone's benefit).
    - eviks 2y ago
      It's also billions of dollars of gain: every single future engineer won't have to waste time due to 13% worse design. But jj supports git as a backend, so not clear what fracturing you mean, do people using magit front-end fracture?
    - lawn 2y ago
      The upside with jujutsu though is that it's completely compatible with Git and you can work on the same repository with Jujutsu while your coworkers use Git. This allows the people who want the 15% gain to have it, while not forcing anyone to do a costly migration.
      - KerrAvon 2y ago
        I know people who really hate git because the UI is so awful, and it’s (theoretically) way more than a 15% gain for them. They’ll get to stop rubbing broken glass against their legs every day.
        SansGuidon 2y ago
        Git feels like solving puzzles everytime there are branches or collaboration made on a repo. So every day. Most productive days are when I dont need to use git. JJ is a workaround for git pains but the UX is not mature enough for replacing git yet. Having distinct local working copies of same repo per git branch still works great, not stash needed, no conflicts or pain with local wip and drafts changes overwritten by pull. No blocker for switching branches. No reset hard/soft whatever. And makes files comparisons easier and makes my git workflows easier. I still feel vcs could be simpler and solved problem if more engineers care about the topic of vcs and generally speaking about the ux of their main tools instead of creating new TUI and plugins to workaround broken ones.
  - stouset 2y ago
    Because every person in here who’s actually used jj is telling you straight up that it’s less complicated. Using jj is less complicated in—as far as I can tell with six months of conversion—actually 100% of the time. I spent one day adapting and maybe two week of having to look something up every other day. And now all of git’s infamous pain points are gone. There is no index. There is no stash. Rebase conflicts are (and rebasing in general is) no longer painful. Jumping between work is a no-op. Fixing up earlier work is a no-op. There are no modal “interim” states like during conflicts where you have to abort or continue to get back to normal. You don’t have to be a git god to run into the many sharp edges of git, and all of the “but my workflow is simple” comments break down upon even cursory inspection. Everyone’s workflow is simple until a rebase goes wrong, or they unstash in the wrong branch, or they need to unfuck an earlier commit, and that list goes on and on. And when you’re in these states you have no practical way to save or persist incomplete work. Jujutsu is both more powerful and simpler, and I say that as someone who knows git inside and out and who’s used it pre-GitHub.
    - ocular-rockular 2y ago
      Okay, happy it works for you. Still don't see a point.
      - SansGuidon 2y ago
        The point for me is to build better and remove the need to know so much about vcs. Git is powerful but requires too much knowledge about git itself to get things done or to tackle possible conflicts in collaboration. Jujutsu tried to remove some of the concepts or make a better ui, to remove some complications. It's like providing an abstraction like python instead of C. Yet it's not perfect. I also struggle to transition to jujutsu yet I admit some benefits. But honestly both are yet too complicated and error prone for something as basic as communicate changes and align versions with each other. I'm happy to see initiatives such as jj but it's still an alpha.
  - mamcx 2y ago
    > looks more complicated and verbose than regular gi Is Git not verbose and complicated? It is like the poster child of it among ALL THE OTHER options in his space! --- I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years. I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week. And have some bash scripts around to automate how to back out of rebase hell.
    - steveklabnik 2y ago
      You’re like the perfect audience for jj. Give it a try with some of your git repos. If you hate it, easy to go back to git afterwards. But I think you’ll like it.
      - mamcx 2y ago
        Ironically the major thing that blocks me is the need for more adoption. I predict I will have enough of it in the next mess of trying to stack PRs or resolve another rebase of 30 steps.
    - ocular-rockular 2y ago
      Not to me.
- neandrake 2y ago
  Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
  - fallingsquirrel 2y ago
    I'm not a heavy jj user. But as I understand it, git-rerere is bolted on top and not well integrated. It just stores resolutions locally on each machine in .git/rr-cache. You need extra steps to share resolutions between contributors. https://stackoverflow.com/questions/12566023/sharing-rerere-cache https://stackoverflow.com/questions/12566023/sharing-rerere-... In jj, resolutions are first-class objects—treated the same as any normal commit, pushed/pulled like normal, etc.
    - keybored 2y ago
      rerere is indeed bolted on. Linus doesn’t want people who he pulls from to back-merge, i.e. to merge at “random points” from him into their trees to keep up to date. But what about merge conflicts? Then he has to deal with them. So then he might begrudgingly ask them to back-merge right before making a pull: a real zig-zag pattern. First-class conflicts would solve all that I think.
  - stouset 2y ago
    In theory yes. In practice I’ve had it enabled since it was first released and it helps… some?
  - martinvonz 2y ago
    In some cases, yes, but I think the way jj handles conflicts is easier to follow. You can see the conflict resolution in `jj diff` and you can rebase it like a regular commit. rerere's state is harder to understand, I think. See https://github.com/martinvonz/jj/issues/175#issuecomment-1079831788 https://github.com/martinvonz/jj/issues/175#issuecomment-107... for some more discussion.
- kukkamario 2y ago
  So it is git with rerere.enabled=1?
  - christophilus 2y ago
    Well, I learned something new. I’m doing this first thing Monday morning.
- deleted 2y ago
  [deleted]
emacsen 2y ago
There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control. If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down, maybe the same will happen with git. 2. jj today I use jj today and the biggest advantages for me are not needing to worry as much about the order of operations. I write some code and then I come across a bug. I can pull out the bug and fix it while still working on my existing code. I don't have to go back in time to fix it. I also appreciate not needing to stop just because of a conflict. This is something I miss from SVN, which was similar-ish in that conflicts didn't need to be addressed immediately, only jj's implementation is better. Generally I find the jj workflow to be something that takes a few days of adjustment, then it just makes more sense. 3. The way things will be jj is still relatively early. The commands to interact with git aren't all very intuitive or easy to use. I had to make some aliases to make this easier. More importantly, there's no jj backend yet. Once that happens and it's adopted by forgjo or another forge (Gitlab, Github), I think we'll see a big shift towards it. I think git is going to be around a long time, but the day to day use of jj is so much nicer than git that I hope it will gain fast adoption.
- yuppiepuppie 2y ago
  I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. Yes, I know that some code bases are too far gone for major enhancements…
  - rakoo 2y ago
    If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible
MarceColl 2y ago
And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.
- edflsafoiewq 2y ago
  Switch to branch for thing 1, work on it, commit, switch to branch for thing 2, work on it, commit, ...
  - MarceColl 2y ago
    Do you stash or create a commit with potentially partial work? What do you name that commit?
    - edflsafoiewq 2y ago
      Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.
      - stouset 2y ago
        And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc. Tools like the stash are band aids that come with their own set of “fun” failure modes.
        edflsafoiewq 2y ago
        If you don't like stash, then use WIP commits like I said. The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.
tonyfinn 2y ago
Author here: The biggest benefit for me is the ability to work on change N+1 (or sometimes even N+2 also) while change N is being reviewed without subjecting myself to constant merge resolution if I need to update change N due to e.g. reviewer feedback, issues in pipelines, etc. `rerere` helps somewhat, but the flow is much nicer when I can just rewrite one commit and everything downstream updates itself. The others are also listed in "the good" section of the article, but that's the biggest one. How much of a benefit that is for you will really depend on your usage patterns - maybe it's solving a problem you don't have. But the nice thing is since it's git compatible, people for whom this solves a problem can use jj, without having to migrate their whole team/company from git, unlike other solutions like fossil, darcs or pijul.
- stouset 2y ago
  I commented on exactly this elsewhere in the thread. It’s hard to understate how insanely useful it is to be able to painlessly edit earlier history even when there are later threads of work based on it. Also in my experience everyone says “my default workflow is easy” when you talk about an alternative VCS but in every other context they complain about how often that workflow starts getting exceptional: rebase conflicts, stash conflicts, WIP commits, uncommitted work accidentally blown away, etc.
rc00 2y ago
[flagged]
rc00 2y ago
> Is there a specific usecase i'm not understanding? It's written in Rust.
ilyagr 2y ago
I find the most benefit from `jj` when I'm preparing some commits for review and I want to make them tell a coherent story. I often want to then rearrange commits, split or merge them, move things from one to another. For people who work on repos by themselves or with a small number of others, the advantages of `jj` would be smaller in most cases, I would think.
mamcx 2y ago
One of the devs I hire tries unsuccessfully for 2 weeks to merge, rebase, fix, and refactor pr of moving a lot of things. I did it in half a day. Git is bad.
SansGuidon 2y ago
Funny thing, I'm becoming an evangelist of Jujutsu but somehow I found myself stuck for 30 minutes with Jujutsu not being able to push a desired branch/commit, and Jujutsu had made my local git copy in detached HEAD. In the end I created a few useless branches through jj, and was still not able to articulate or understand through the docs how to sort my situation and tell jj that I want to move my latest work on main, nor to find a way to rebase/merge my accidentally created bookmarks/branches on top of main. Then ended up switching back to git, redo all the coding again and push. Having to understand either jj or git models through tons of tutorials and videos, while I just want a way to dialog easily with my changes in my own vocabulary and my own mental model, make me believe I'm a lost cause or I need my own VCS Anyway Jujutsu stil feels great, I just hope now to not need to suffer like I did with git.

lawn 2y ago

One advantage is that jujutsu tracks merge conflicts so you don't end up in a situation where you'll have to resolve the same conflict more than once, which may sometimes happen with git.

ocular-rockular 2y ago
But why build a whole VCS around that one use case? I looked through the docs and honestly it looks like it complicates life instead of making it easier. edit: everyone is so focused on the "single use case" part and not the fact that it looks more complicated and verbose than regular git. Unless everyone using it is some git god that runs into edge cases left and right... maybe my workflow is just not that complicated to need a solution to problems I don't have?
- lawn 2y ago
  It's not the only improvement though, depending on your workflow. Another thing you can do is work on multiple branches at the same time. See: https://ofcr.se/jujutsu-merge-workflow https://ofcr.se/jujutsu-merge-workflow
- keybored 2y ago
  It’s not necessarily the only use case. But as I’ve read (according to Martin) doing it this way simplifies the implementation a lot. You track everything directly in the DB. In turn you don’t have to care about all sorts of states like being in conflicted git-am state, conflicted git-merge, etc.—these states cannot happen, it’s all in the DB (not some dirty working tree state where some flags or files somewhere in `.git` or `.jj` tell you “there are some conflict markers thereabouts, enjoy”). And that frames it in terms of being easier for the people implementing jj. But I think it will also benefit us users by making it easier for them to create streamlined tools. git-rebase(1) and all that is great and all. But definitely messy. And we only recently got `--update-refs` to update dependent branches, which is kind of late considering how important branches are in Git.
- zug_zug 2y ago
  Moreover, even if it was say 15% better than git (and I doubt it is), the overhead of moving a whole industry across VCs is billions of dollars of loss. Every single engineer has to start over in their mastery experience by learning all the new quirks and issues, and all the tools, libraries, pipelines need to be rewritten. IMO better to support the dominant tooling than invest in fracturing one of the few areas where engineers can agree on something for once (to everyone's benefit).
  - eviks 2y ago
    It's also billions of dollars of gain: every single future engineer won't have to waste time due to 13% worse design. But jj supports git as a backend, so not clear what fracturing you mean, do people using magit front-end fracture?
  - lawn 2y ago
    The upside with jujutsu though is that it's completely compatible with Git and you can work on the same repository with Jujutsu while your coworkers use Git. This allows the people who want the 15% gain to have it, while not forcing anyone to do a costly migration.
    - KerrAvon 2y ago
      I know people who really hate git because the UI is so awful, and it’s (theoretically) way more than a 15% gain for them. They’ll get to stop rubbing broken glass against their legs every day.
      - SansGuidon 2y ago
        Git feels like solving puzzles everytime there are branches or collaboration made on a repo. So every day. Most productive days are when I dont need to use git. JJ is a workaround for git pains but the UX is not mature enough for replacing git yet. Having distinct local working copies of same repo per git branch still works great, not stash needed, no conflicts or pain with local wip and drafts changes overwritten by pull. No blocker for switching branches. No reset hard/soft whatever. And makes files comparisons easier and makes my git workflows easier. I still feel vcs could be simpler and solved problem if more engineers care about the topic of vcs and generally speaking about the ux of their main tools instead of creating new TUI and plugins to workaround broken ones.
- stouset 2y ago
  Because every person in here who’s actually used jj is telling you straight up that it’s less complicated. Using jj is less complicated in—as far as I can tell with six months of conversion—actually 100% of the time. I spent one day adapting and maybe two week of having to look something up every other day. And now all of git’s infamous pain points are gone. There is no index. There is no stash. Rebase conflicts are (and rebasing in general is) no longer painful. Jumping between work is a no-op. Fixing up earlier work is a no-op. There are no modal “interim” states like during conflicts where you have to abort or continue to get back to normal. You don’t have to be a git god to run into the many sharp edges of git, and all of the “but my workflow is simple” comments break down upon even cursory inspection. Everyone’s workflow is simple until a rebase goes wrong, or they unstash in the wrong branch, or they need to unfuck an earlier commit, and that list goes on and on. And when you’re in these states you have no practical way to save or persist incomplete work. Jujutsu is both more powerful and simpler, and I say that as someone who knows git inside and out and who’s used it pre-GitHub.
  - ocular-rockular 2y ago
    Okay, happy it works for you. Still don't see a point.
    - SansGuidon 2y ago
      The point for me is to build better and remove the need to know so much about vcs. Git is powerful but requires too much knowledge about git itself to get things done or to tackle possible conflicts in collaboration. Jujutsu tried to remove some of the concepts or make a better ui, to remove some complications. It's like providing an abstraction like python instead of C. Yet it's not perfect. I also struggle to transition to jujutsu yet I admit some benefits. But honestly both are yet too complicated and error prone for something as basic as communicate changes and align versions with each other. I'm happy to see initiatives such as jj but it's still an alpha.
- mamcx 2y ago
  > looks more complicated and verbose than regular gi Is Git not verbose and complicated? It is like the poster child of it among ALL THE OTHER options in his space! --- I was a heavy user of mercurial, I learned it in a day or two, then maybe only had one or 2 major complications for years. I use git now for 'social' pressure reasons, and despite I use it more heavily than hg, i need to check stuff every week. And have some bash scripts around to automate how to back out of rebase hell.
  - steveklabnik 2y ago
    You’re like the perfect audience for jj. Give it a try with some of your git repos. If you hate it, easy to go back to git afterwards. But I think you’ll like it.
    - mamcx 2y ago
      Ironically the major thing that blocks me is the need for more adoption. I predict I will have enough of it in the next mess of trying to stack PRs or resolve another rebase of 30 steps.
  - ocular-rockular 2y ago
    Not to me.
neandrake 2y ago
Git’s rerere functionality should address this, right? https://git-scm.com/book/en/v2/Git-Tools-Rerere https://git-scm.com/book/en/v2/Git-Tools-Rerere
- fallingsquirrel 2y ago
  I'm not a heavy jj user. But as I understand it, git-rerere is bolted on top and not well integrated. It just stores resolutions locally on each machine in .git/rr-cache. You need extra steps to share resolutions between contributors. https://stackoverflow.com/questions/12566023/sharing-rerere-cache https://stackoverflow.com/questions/12566023/sharing-rerere-... In jj, resolutions are first-class objects—treated the same as any normal commit, pushed/pulled like normal, etc.
  - keybored 2y ago
    rerere is indeed bolted on. Linus doesn’t want people who he pulls from to back-merge, i.e. to merge at “random points” from him into their trees to keep up to date. But what about merge conflicts? Then he has to deal with them. So then he might begrudgingly ask them to back-merge right before making a pull: a real zig-zag pattern. First-class conflicts would solve all that I think.
- stouset 2y ago
  In theory yes. In practice I’ve had it enabled since it was first released and it helps… some?
- martinvonz 2y ago
  In some cases, yes, but I think the way jj handles conflicts is easier to follow. You can see the conflict resolution in `jj diff` and you can rebase it like a regular commit. rerere's state is harder to understand, I think. See https://github.com/martinvonz/jj/issues/175#issuecomment-1079831788 https://github.com/martinvonz/jj/issues/175#issuecomment-107... for some more discussion.
kukkamario 2y ago
So it is git with rerere.enabled=1?
- christophilus 2y ago
  Well, I learned something new. I’m doing this first thing Monday morning.
deleted 2y ago
[deleted]

emacsen 2y ago

There are three answers to this. 1. If it works for you, no need to stop I remember plenty of people who used SVN saying why did they need to use git. In fact, I remember companies complaining about distributed version control generally, saying they preferred centralized version control. If it works for you, you can keep using it. No one will stop you, but you may find that just as SVN users have largely shrunk down, maybe the same will happen with git. 2. jj today I use jj today and the biggest advantages for me are not needing to worry as much about the order of operations. I write some code and then I come across a bug. I can pull out the bug and fix it while still working on my existing code. I don't have to go back in time to fix it. I also appreciate not needing to stop just because of a conflict. This is something I miss from SVN, which was similar-ish in that conflicts didn't need to be addressed immediately, only jj's implementation is better. Generally I find the jj workflow to be something that takes a few days of adjustment, then it just makes more sense. 3. The way things will be jj is still relatively early. The commands to interact with git aren't all very intuitive or easy to use. I had to make some aliases to make this easier. More importantly, there's no jj backend yet. Once that happens and it's adopted by forgjo or another forge (Gitlab, Github), I think we'll see a big shift towards it. I think git is going to be around a long time, but the day to day use of jj is so much nicer than git that I hope it will gain fast adoption.

yuppiepuppie 2y ago
I get what you are saying about the nicer workflows for those cases. However, why would the contributors to jj not just try to make git better by addressing these weaknesses? I’m not being glib, just that it puzzzles me when a new oss comes out that does the same thing as another tool but a a bit different. I would have though that there is a way to have a git plug-in or even a way to contribute to git to enhance the issues outlined. Yes, I know that some code bases are too far gone for major enhancements…
- rakoo 2y ago
  If anything, lazygit has shown it is possible to have more natural workflows on top of git as demonstrated by https://www.youtube.com/watch?v=CPLdltN7wgE https://www.youtube.com/watch?v=CPLdltN7wgE, so it is indeed possible

MarceColl 2y ago

And what are the steps when you work on 3 things at the same time (you are working on PR #2 + fixing issues in PR#1 + a hotfix needs to be deployed for an issue)? Or when you need to continue fixing things on the PR? On the absolute happy path what you do above is the same I do, where jj shines is when you het out of the happy path.

edflsafoiewq 2y ago
Switch to branch for thing 1, work on it, commit, switch to branch for thing 2, work on it, commit, ...
- MarceColl 2y ago
  Do you stash or create a commit with potentially partial work? What do you name that commit?
  - edflsafoiewq 2y ago
    Personally I usually stash if it's partial work I'm going to return to soon. But you can create a commit if you want. Just name it 'WIP' or 'temp' or something. When you come back and finish it you can write the proper commit message.
    - stouset 2y ago
      And then you have to remember which branch the each entry of the stash was on, deal with unstashing conflicts, remember to drop the latest stash after fixing those, etc. Tools like the stash are band aids that come with their own set of “fun” failure modes.
      - edflsafoiewq 2y ago
        If you don't like stash, then use WIP commits like I said. The easiest and by far most common thing to do of course is to just complete the commit you're working on before switching branches.

tonyfinn 2y ago

Author here: The biggest benefit for me is the ability to work on change N+1 (or sometimes even N+2 also) while change N is being reviewed without subjecting myself to constant merge resolution if I need to update change N due to e.g. reviewer feedback, issues in pipelines, etc. `rerere` helps somewhat, but the flow is much nicer when I can just rewrite one commit and everything downstream updates itself. The others are also listed in "the good" section of the article, but that's the biggest one. How much of a benefit that is for you will really depend on your usage patterns - maybe it's solving a problem you don't have. But the nice thing is since it's git compatible, people for whom this solves a problem can use jj, without having to migrate their whole team/company from git, unlike other solutions like fossil, darcs or pijul.

stouset 2y ago
I commented on exactly this elsewhere in the thread. It’s hard to understate how insanely useful it is to be able to painlessly edit earlier history even when there are later threads of work based on it. Also in my experience everyone says “my default workflow is easy” when you talk about an alternative VCS but in every other context they complain about how often that workflow starts getting exceptional: rebase conflicts, stash conflicts, WIP commits, uncommitted work accidentally blown away, etc.

rc00 2y ago

[flagged]

rc00 2y ago

> Is there a specific usecase i'm not understanding? It's written in Rust.

ilyagr 2y ago

I find the most benefit from `jj` when I'm preparing some commits for review and I want to make them tell a coherent story. I often want to then rearrange commits, split or merge them, move things from one to another. For people who work on repos by themselves or with a small number of others, the advantages of `jj` would be smaller in most cases, I would think.

mamcx 2y ago

One of the devs I hire tries unsuccessfully for 2 weeks to merge, rebase, fix, and refactor pr of moving a lot of things. I did it in half a day. Git is bad.

SansGuidon 2y ago

Funny thing, I'm becoming an evangelist of Jujutsu but somehow I found myself stuck for 30 minutes with Jujutsu not being able to push a desired branch/commit, and Jujutsu had made my local git copy in detached HEAD. In the end I created a few useless branches through jj, and was still not able to articulate or understand through the docs how to sort my situation and tell jj that I want to move my latest work on main, nor to find a way to rebase/merge my accidentally created bookmarks/branches on top of main. Then ended up switching back to git, redo all the coding again and push. Having to understand either jj or git models through tons of tutorials and videos, while I just want a way to dialog easily with my changes in my own vocabulary and my own mental model, make me believe I'm a lost cause or I need my own VCS Anyway Jujutsu stil feels great, I just hope now to not need to suffer like I did with git.