4 ms·

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

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.
- nchmy 1y ago
  for me, everything git is a pain point. But its not so much painpoints that it addresses, as it is that it just makes entirely new things dead-simple to do, especially via jjui. "megamerges" are one such example. ive shared many links, here and in other posts
  - nocman 1y ago
    > for me, everything git is a pain point Yeah, I was looking for something (or "things") specific. An "I hate everything about it" explanation doesn't really compel me to try out the alternative. > "megamerges" are one such example. ive shared many links, here and in other posts I read through one megamerge link you shared ( https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... ). So the argument seems to be (forgive me if I'm reading this wrong), if you have multiple versions of a single set of source files that all have differing changes, for you JuJutsu makes it easier (easier then git, that is) to merge them into the final commit you want to end up with. Is that correct? Just trying to make sure I understand. Honestly, after reading that article I am still not feeling the need to try Jujustu out. I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!".
    - nchmy 1y ago
      "multiple versions" = feature branches, possibly all in progress, probably all related. In a couple seconds, you can create a merge on top of all of them to join up their combined functionality/changes, work on top of that ON ALL OF THEM AT ONCE, and then squash all the relevant changes into the respective PRs that others (who are just using git) can review and merge into main. At this point A LOT has been written in this and other threads, as well as lots of essays and tutorials about how jj just completely transforms your workflow. If you're curious, you'll seek it out. If not, that's fine as well.
      - typpilol 1y ago
        What does the history look like then? Just a single merge from a ton of branches or?
        KingMob 1y ago
        The parent is describing the megamerge pattern, which is a way to work on multiple branches at once. You don't have to do that, and you rarely push it to others. History looks the same as git, usually, although I end up rebasing more than I ever did in git, since it's easier and safer.
    - KingMob 1y ago
      > I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!". You might not find that feature, but I'd suggest giving it a go anyway. The list of jj technical superiorities is short, but the numerous quality-of-life DX improvements all add up to pleasant, fearless version control. Even without editor support or a UI, I abandoned git forever last year after using jj for a couple weeks. Just my $.02.
      - nchmy 1y ago
        Jjui is an incredible TUI for jj. Its the only way I interact with jj
    - 1y ago
- BeetleB 1y ago
  I would think the obvious answer is how jj deals with merge conflicts. In git, if you get a conflict, you feel like you have to resolve it now. With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. A conflict is not at all a blocker.
  - touristtam 1y ago
    > With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. Sorry? You what? How do you know which bit from which source goes where?
    - BeetleB 1y ago
      Here's a typical scenario. You do a git pull, just so your branch isn't so out of sync. Immediately you get merge conflicts. You then tell jj "Hey, I'll deal with this later", and make a branch off of the last commit that was conflict free and continue your work there. jj stores the conflict as is, but your branch is conflict free. When you feel you have the energy to deal with the conflict, you switch to the branch that has the conflict, and fix the issue(s). Then you can manipulate the graph (rebase, whatever) so you can have everything in one branch - your changes and the changes you pulled in.
      - 1718627440 1y ago
        So you essentially do a fast-forward until the first commit with a merge commit and then take the previous one? Sounds like something that could also become a flag for git merge.
        steveklabnik 1y ago
        Git won’t let the portion of the branch that’s still conflicted remain in conflict while you go and work on the other part.
        1y ago
- stavros 1y ago
  For me, it's two things: 1. I understood git better after ten minutes of jj than after fifteen years of git. Git just doesn't expose its underlying data model as well as jj does. I guess, if you already know git well, this isn't going to make a difference for you. 2. This question is a bit like asking what can I do with a calculator that I can't do with pen and paper? Technically, nothing, but everything will be so much easier that you'll be much more likely to use it. Even though I can, technically, stash my worktree and jump to another commit with git, it's so fiddly to unstash (especially with multiple stacked switches/stashes) that I just never did it. With jj, I leave commits in the middle and jump to other commits (to fix a bug or make a small change I noticed I need while working on a larger change) all the time, because there's zero friction. jj just removes all the friction that's prevalent in git. Things are easy in jj that in git are merely possible.
  - BeetleB 1y ago
    > With jj, I leave commits in the middle and jump to other commits (to fix a bug or make a small change I noticed I need while working on a larger change) all the time, because there's zero friction. For git users who are wondering "What friction? I just git stash and jump to another branch": In jj, you just jump without needing to type any command like git stash.
    - socalgal2 1y ago
      git stash is not that simple. you'd need to remember what branch that stash applies to to get back to where you were. I'm new to jj. I'm still mixed on if I like it not. I think it's mostly familiarity. For example, switching to a commit puts things in the state before the files were committed. All my projects have a presumit step that says "hey! commit your files!" so they are all incompatible with jj at the moment or at leas the default. I end up having to do temp stuff like `jj new` (ok, now they're committed). Now run my presubmit scripts. Then `jj undo` so I don't have this unneeded commit. That said, I'm sure there's a better way, I just haven't gotten used jj yet. Others have said this, `jj undo` and `jj op restore` have been lifesavers though. No matter what I do I can get back to where I was before I messed up.
- senekor 1y ago
  Yes and no. Before I started using Jujutsu, I didn't have any pain points with using Git. I didn't understand what all the fuss was about. Git works well! So I totally understand how most Git users have that same reaction when hearing about Jujutsu. I think the reason I even tried it out in the first place was because Steve Klabnik wrote a tutorial about it. I have a lot of respect for him, because the Rust book is really good. So I though: If Steve thinks it's worth it, I should probably check it out. Now that I'm used to jj, going back reveals like 100 things that are immediately super annoying when using git. I don't feel like writing it all down TBH. :-) In a general sense, Jujutsu get's out of your way much better than Git. There are a lot of situations where Git blocks you from continuing to work. Have a merge conflict? Stop working, fix it right now. Want to check out another branch? Nu-uh, clean up your dirty worktree first. jj doesn't do that. Have a conflict? I'll record it in the commit, fix it whenever you like. Checking out another branch? No worries, I'll keep your work in progress safe in a commit.

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.

nchmy 1y ago
for me, everything git is a pain point. But its not so much painpoints that it addresses, as it is that it just makes entirely new things dead-simple to do, especially via jjui. "megamerges" are one such example. ive shared many links, here and in other posts
- nocman 1y ago
  > for me, everything git is a pain point Yeah, I was looking for something (or "things") specific. An "I hate everything about it" explanation doesn't really compel me to try out the alternative. > "megamerges" are one such example. ive shared many links, here and in other posts I read through one megamerge link you shared ( https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj-absorb/ https://v5.chriskrycho.com/journal/jujutsu-megamerges-and-jj... ). So the argument seems to be (forgive me if I'm reading this wrong), if you have multiple versions of a single set of source files that all have differing changes, for you JuJutsu makes it easier (easier then git, that is) to merge them into the final commit you want to end up with. Is that correct? Just trying to make sure I understand. Honestly, after reading that article I am still not feeling the need to try Jujustu out. I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!".
  - nchmy 1y ago
    "multiple versions" = feature branches, possibly all in progress, probably all related. In a couple seconds, you can create a merge on top of all of them to join up their combined functionality/changes, work on top of that ON ALL OF THEM AT ONCE, and then squash all the relevant changes into the respective PRs that others (who are just using git) can review and merge into main. At this point A LOT has been written in this and other threads, as well as lots of essays and tutorials about how jj just completely transforms your workflow. If you're curious, you'll seek it out. If not, that's fine as well.
    - typpilol 1y ago
      What does the history look like then? Just a single merge from a ton of branches or?
      - KingMob 1y ago
        The parent is describing the megamerge pattern, which is a way to work on multiple branches at once. You don't have to do that, and you rarely push it to others. History looks the same as git, usually, although I end up rebasing more than I ever did in git, since it's easier and safer.
  - KingMob 1y ago
    > I'm still open to being convinced, but have yet to see anything that makes me go "wow, I need to try that!". You might not find that feature, but I'd suggest giving it a go anyway. The list of jj technical superiorities is short, but the numerous quality-of-life DX improvements all add up to pleasant, fearless version control. Even without editor support or a UI, I abandoned git forever last year after using jj for a couple weeks. Just my $.02.
    - nchmy 1y ago
      Jjui is an incredible TUI for jj. Its the only way I interact with jj
  - 1y ago
BeetleB 1y ago
I would think the obvious answer is how jj deals with merge conflicts. In git, if you get a conflict, you feel like you have to resolve it now. With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. A conflict is not at all a blocker.
- touristtam 1y ago
  > With jj, most of the times I get merge conflicts, I simply ignore them and deal with them later. Sorry? You what? How do you know which bit from which source goes where?
  - BeetleB 1y ago
    Here's a typical scenario. You do a git pull, just so your branch isn't so out of sync. Immediately you get merge conflicts. You then tell jj "Hey, I'll deal with this later", and make a branch off of the last commit that was conflict free and continue your work there. jj stores the conflict as is, but your branch is conflict free. When you feel you have the energy to deal with the conflict, you switch to the branch that has the conflict, and fix the issue(s). Then you can manipulate the graph (rebase, whatever) so you can have everything in one branch - your changes and the changes you pulled in.
    - 1718627440 1y ago
      So you essentially do a fast-forward until the first commit with a merge commit and then take the previous one? Sounds like something that could also become a flag for git merge.
      - steveklabnik 1y ago
        Git won’t let the portion of the branch that’s still conflicted remain in conflict while you go and work on the other part.
        1y ago
stavros 1y ago
For me, it's two things: 1. I understood git better after ten minutes of jj than after fifteen years of git. Git just doesn't expose its underlying data model as well as jj does. I guess, if you already know git well, this isn't going to make a difference for you. 2. This question is a bit like asking what can I do with a calculator that I can't do with pen and paper? Technically, nothing, but everything will be so much easier that you'll be much more likely to use it. Even though I can, technically, stash my worktree and jump to another commit with git, it's so fiddly to unstash (especially with multiple stacked switches/stashes) that I just never did it. With jj, I leave commits in the middle and jump to other commits (to fix a bug or make a small change I noticed I need while working on a larger change) all the time, because there's zero friction. jj just removes all the friction that's prevalent in git. Things are easy in jj that in git are merely possible.
- BeetleB 1y ago
  > With jj, I leave commits in the middle and jump to other commits (to fix a bug or make a small change I noticed I need while working on a larger change) all the time, because there's zero friction. For git users who are wondering "What friction? I just git stash and jump to another branch": In jj, you just jump without needing to type any command like git stash.
  - socalgal2 1y ago
    git stash is not that simple. you'd need to remember what branch that stash applies to to get back to where you were. I'm new to jj. I'm still mixed on if I like it not. I think it's mostly familiarity. For example, switching to a commit puts things in the state before the files were committed. All my projects have a presumit step that says "hey! commit your files!" so they are all incompatible with jj at the moment or at leas the default. I end up having to do temp stuff like `jj new` (ok, now they're committed). Now run my presubmit scripts. Then `jj undo` so I don't have this unneeded commit. That said, I'm sure there's a better way, I just haven't gotten used jj yet. Others have said this, `jj undo` and `jj op restore` have been lifesavers though. No matter what I do I can get back to where I was before I messed up.
senekor 1y ago
Yes and no. Before I started using Jujutsu, I didn't have any pain points with using Git. I didn't understand what all the fuss was about. Git works well! So I totally understand how most Git users have that same reaction when hearing about Jujutsu. I think the reason I even tried it out in the first place was because Steve Klabnik wrote a tutorial about it. I have a lot of respect for him, because the Rust book is really good. So I though: If Steve thinks it's worth it, I should probably check it out. Now that I'm used to jj, going back reveals like 100 things that are immediately super annoying when using git. I don't feel like writing it all down TBH. :-) In a general sense, Jujutsu get's out of your way much better than Git. There are a lot of situations where Git blocks you from continuing to work. Have a merge conflict? Stop working, fix it right now. Want to check out another branch? Nu-uh, clean up your dirty worktree first. jj doesn't do that. Have a conflict? I'll record it in the commit, fix it whenever you like. Checking out another branch? No worries, I'll keep your work in progress safe in a commit.