4 ms·

So... git rebase -i?

• nomel 4mo ago
  Definitely not. Switch to a previous commit, make edits, changes propagate into the future commits (including into a git repo if you wish [1]) Jj is not git and is not a git tool, it just (thankfully) uses git as a backend, so you can still carry on with the rest of the world. [1] https://news.ycombinator.com/item?id=47765759 https://news.ycombinator.com/item?id=47765759
  • deleted 4mo ago
    [deleted]
  • ahepp 4mo ago
    > Switch to a previous commit, make edits, changes propagate into the future commits In what way is that different from using `git rebase -i` to edit a commit?
    • stouset 4mo ago
      You can literally jump into a commit and edit its contents directly, and everything is auto-rebased on top. There are no modal “sorry rebase failed, best of luck” gotchas. There are no “oops I put the wrong thing in the wrong part of the rebase and now I have to abort and start all over” gotchas. It’s rebase, but without all the extra work, mental overhead, failure cases, and effort.
      • matheusmoreira 4mo ago
        How does it just auto-rebase everything without failing though? If you edit something later commits depend on, then you get merge conflicts. Are you implying that jj just automatically handles all this?
        • steveklabnik 4mo ago
          jj allows your commits to stay in a conflicted state until you choose to resolve them. I wrote about this a month ago: https://news.ycombinator.com/item?id=47767292 https://news.ycombinator.com/item?id=47767292
          • matheusmoreira 4mo ago
            I see. It doesn't deal with the conflict, it just proceeds regardless. I'm curious about how it works internally. Does it do something like commit the conflict and soft reset later?
            • stouset 4mo ago
              The conflict markers are a first-class citizen in the repo. jj tells you when a commit has a conflict, and you can go edit it at your leisure. It also does prevent you from doing some things with branches in a conflicted state, like pushing them. You might not think this is that big a deal, but this also means you don’t have to resolve the entire thing in one go. Plenty of times with complicated rebases in git, I’ve not been 100% certain about the path towards resolving it. But jumping around to view various commits when you’re in the rebase-conflict state is painful. In jj you can just switch to an earlier commit, tweak it there, jump to a later commit, see how it looks, etc. It removes 98% of the pain. It also dovetails nicely with other aspects of jj. Since rebases happen automatically and constantly, they are usually tiny. If there’s a conflict, it’s caught right when you do the thing and not four hours later when that part is no longer fresh in mind. And the op log lets you restore and undo actions atomically, which makes undoing a fuck-up a no-op.
              • bentcorner 4mo ago
                I've come to the opinion that conflicts should be committed and merge fixes should be in another commit afterwards. Arguably even if the merge fix is trivial.
                • 4mo ago
• ai_slop_hater 4mo ago
  git rebase -i kinda sucks once you tried jj.
• 9029 4mo ago
  I'd recommend reading the post, it's not that long
  • raincole 4mo ago
    As someone who doesn't know jj and read this article, it does sound like `git rebase -i` to me. I'm sure that if I actually spent time learning jj I'd know the difference though.
• idoubtit 4mo ago
  No, more like: git rebase -i # squash all the commits (e.g. in vim with ctrl-v) git reset HEAD^ git add -p # interactively pickup the RED hunks git ci -m RED The main difference to jj is that the RED commit is created later with git.
  • nine_k 4mo ago
    But isn't the flow nearly identical with jj, because the key part, the moving of hunks, is interactive (aka manual) anyway?