5 ms·

A few advantages for me, even for the same 5 commands I use over and over: - undo - shuffling commits around with squash, split, and rebase is much better tha

by dcre 15d ago

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

1718627440 15d ago
> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase Can you explain this to me? I feel like Git is pretty easy there. - select oldest commit to modify - move the commits around with a mouse or the cursor - close the editor to apply Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me. Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).
- dullcrisp 14d ago
  It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
  - markalby 14d ago
    that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management. I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
    - stouset 14d ago
      The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO. With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.
    - dcre 14d ago
      I also used to use a GUI (https://gitup.co/ https://gitup.co/) for that reason, and jj has completely replaced it for me.
  - xyzzy_plugh 14d ago
    > say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git. This is the best pitch for jj I have seen yet. This should practically be the first text on their website.
  - 1718627440 14d ago
    > I don’t like to think about how I’d do that with git. git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~ Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.
    - dcre 14d ago
      It's great to use what you prefer, but I don't think most people would see that and think "ooh, convenient!"
    - yencabulator 14d ago
      Now imagine having other branches starting from the commits that just got rebased, also including merge commits. jj handles that just as well.
      - 1718627440 14d ago
        git rebase --onto --rebase-merges ?
        yencabulator 14d ago
        How many of those do you need? How do find the correct arguments and git checkouts to do before? Are you sure you remembered to do everything? What if there are merge commits? All of that is automatic with jj.
        1718627440 14d ago
        > How many of those do you need? How many do I want? > How do find the correct arguments How do you find the correct arguments for jj? > and git checkouts to do before? Why would I do a checkout before? I don't want to modify the worktree? Maybe I in fact also want to alter the worktree, but that's unrelated. > Are you sure you remembered to do everything? Am I sure I have all my files ordered? No. Does it matter? Also no. Are you sure you have no bug in your commits in JJ? If I want git to alter some set of commit chains, I can tell it to. Actually I never needed to do that, because I don't work on several thousand branches at the same time. I prefer it to not alter unrelated branches automatically, just because some earlier commit changed that is in both. Such things actually undermines the trust I have in a tool, because it does things I haven't told it to do, even if I'm aware it does these things. > What if there are merge commits? Then I resolve them. Merge conflicts occur, because there is some actual conflicting change and often it is also semantic. These don't go a way by changing the VCS. On a theoretic basis, these require outside information(=decisions) that is not there yet. There are more often semantic conflicts, that are not syntactic, then there are the other way around. If you are referring to doing the same merge conflicts again, I can tell Git to resolve them automatically too, but it actually occurred too often, that this is not actually what I want, so I actually dislike that feature now.
  - umvi 14d ago
    > I don’t like to think about how I’d do that with git. git cherry-pick + git rebase -i (to swap commit order)? ?
    - dullcrisp 14d ago
      Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah. But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.
      - 1718627440 14d ago
        > Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use. > then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work. > though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that. > so you lose your commit message You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never. > maybe detach your head I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state. > start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve. > I’m usually going back to git reflog to try to find the last point where history made sense Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert. > But I said I didn’t want to think about this anymore. Yet you do in JJ.
- dcre 14d ago
  Here's the post that made it click for me. It works through a practical example in both git and jj. https://lottia.net/notes/0013-git-jujutsu-miniature.html https://lottia.net/notes/0013-git-jujutsu-miniature.html

by dcre 15d ago

1718627440 15d ago

> - shuffling commits around with squash, split, and rebase is much better than git’s interactive rebase Can you explain this to me? I feel like Git is pretty easy there. - select oldest commit to modify - move the commits around with a mouse or the cursor - close the editor to apply Sure, the first step can go away (which is what they do with git history), but the rest seems pretty optimal to me. Alternatively I can add changes to older commits by recording them on top (--fixup) and tell git to auto apply them (--autosquash). I can also tell git to do the first thing automatically (git absorb, I believe it's inspired by jj).

dullcrisp 14d ago
It does take a few days to stop missing interactive rebase. But say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git.
- markalby 14d ago
  that’s the first example I’ve seen these last year so that makes sense to me about jj having better commit management. I rebase a lot using Fork (git gui) and it’s really easy to drag and drop reorder commits, rename, apply as fixups or squash in. I can see how jj makes sense if you’re in the command line, though. And splitting changes from commits in git is really annoying, but it only comes up once in a blue moon for me.
  - stouset 14d ago
    The ability to rebase, reorder, and squash like this only really makes sense with jj’s autorebasing IMO. With git, if you do this, everything after is left orphaned. Even if you have a GUI that does this for you, now rebase conflicts become an enormous pain.
  - dcre 14d ago
    I also used to use a GUI (https://gitup.co/ https://gitup.co/) for that reason, and jj has completely replaced it for me.
- xyzzy_plugh 14d ago
  > say you’re in the middle of working on something and you wish you had a commit you made last week on an experimental branch on the current branch before the last commit you made. That’s jj rebase -r oldercommit --before @-, without interrupting your work. I don’t like to think about how I’d do that with git. This is the best pitch for jj I have seen yet. This should practically be the first text on their website.
- 1718627440 14d ago
  > I don’t like to think about how I’d do that with git. git -c sequence.editor="sed -i '1ip oldercommit'" rebase -i @~ Git using standard UNIX tools for these things instead of a specialized syntax, means I can easily write more complicated automations.
  - dcre 14d ago
    It's great to use what you prefer, but I don't think most people would see that and think "ooh, convenient!"
  - yencabulator 14d ago
    Now imagine having other branches starting from the commits that just got rebased, also including merge commits. jj handles that just as well.
    - 1718627440 14d ago
      git rebase --onto --rebase-merges ?
      - yencabulator 14d ago
        How many of those do you need? How do find the correct arguments and git checkouts to do before? Are you sure you remembered to do everything? What if there are merge commits? All of that is automatic with jj.
        1718627440 14d ago
        > How many of those do you need? How many do I want? > How do find the correct arguments How do you find the correct arguments for jj? > and git checkouts to do before? Why would I do a checkout before? I don't want to modify the worktree? Maybe I in fact also want to alter the worktree, but that's unrelated. > Are you sure you remembered to do everything? Am I sure I have all my files ordered? No. Does it matter? Also no. Are you sure you have no bug in your commits in JJ? If I want git to alter some set of commit chains, I can tell it to. Actually I never needed to do that, because I don't work on several thousand branches at the same time. I prefer it to not alter unrelated branches automatically, just because some earlier commit changed that is in both. Such things actually undermines the trust I have in a tool, because it does things I haven't told it to do, even if I'm aware it does these things. > What if there are merge commits? Then I resolve them. Merge conflicts occur, because there is some actual conflicting change and often it is also semantic. These don't go a way by changing the VCS. On a theoretic basis, these require outside information(=decisions) that is not there yet. There are more often semantic conflicts, that are not syntactic, then there are the other way around. If you are referring to doing the same merge conflicts again, I can tell Git to resolve them automatically too, but it actually occurred too often, that this is not actually what I want, so I actually dislike that feature now.
- umvi 14d ago
  > I don’t like to think about how I’d do that with git. git cherry-pick + git rebase -i (to swap commit order)? ?
  - dullcrisp 14d ago
    Along with the appropriate git stash and git stash pops or git commit -anm wip and git reset HEAD^ so long as you’re not using your staging area for anything, yeah. But if the cherry pick doesn’t cleanly apply at the current HEAD, then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick it if that works (I think it should? though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem) or else maybe detach your head and start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase, and at that point I’m usually going back to git reflog to try to find the last point where history made sense. Or I guess you could just remember that you can introduce arbitrary existing commit refs into an interactive rebase like 1718627440 did. But I said I didn’t want to think about this anymore.
    - 1718627440 14d ago
      > Along with the appropriate git stash and git stash pops If you don't want to do that, you can tell git to do it automatically too? I actually thought I would like that, so I used it for a week. I did not like it at all. > But if the cherry pick doesn’t cleanly apply at the current HEAD If the diff you want to commit isn't applicable to the tree you want to apply it to, it's not going to work, no matter the VCS you use. > then you have to remember to either do the git rebase -i first and pause at the appropriate place to cherry pick You say that like these would be separate operations, but for me these are very much not, I guess like the fact that you need to supply both '-r oldercommit' and '--before @-' are for you. I think this is the point where I actually don't understand your view. Like, we both need to supply two parameters, we need to because this is the operation we want to do. You write two parameters free form, I write one free and select the other from a list. There is a difference, I actually think selecting from a list can be more convenient in some cases, less in others. But I don't get why you write like it would be crazy work. > though I also recall rebase only letting you pause before a commit so you lose your commit message, but that’s probably a me problem It does only let you handle full commits, if that's what you mean, if you want to split a commit you need to provide information how. But that it doesn't sound like you mean that. > so you lose your commit message You can apply commit metadata independently of the tree you want to commit, so that definitely occurs never. > maybe detach your head I bet you don't have issues with detaching the head in JJ, so why do you in Git, it's just a normal state. > start doing surgery because otherwise you’ll be resolving conflicts in two different directions as you cherry pick and then rebase Yes, but that is not because you use Git, but because you wrote the change against some other commit first, which you don't do in your JJ example. You could do that in Git as well and then you only have one set of merges to resolve. > I’m usually going back to git reflog to try to find the last point where history made sense Which is git rebase --abort or git reset @{1}. The latter is always the same, this is as silly as saying I can't remember whether it's jj undo or jj revert. > But I said I didn’t want to think about this anymore. Yet you do in JJ.
dcre 14d ago
Here's the post that made it click for me. It works through a practical example in both git and jj. https://lottia.net/notes/0013-git-jujutsu-miniature.html https://lottia.net/notes/0013-git-jujutsu-miniature.html