Hacker News Reader

Comment by diath | Hacker News Reader

So... git rebase -i?

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.

But isn't the flow nearly identical with jj, because the key part, the moving of hunks, is interactive (aka manual) anyway?

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

> 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?

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.

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?

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

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?

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.

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.

That’s almost definitionally what a merge is.

A merge conflict means that some automated tool couldn’t figure it out. But all a merge is is a commit with two parents and an accompanying diff that shows the process of combining them. A merge conflict isn’t really in any way special. It just means whatever algorithm was used couldn’t do it unambiguously without human help.

I'd recommend reading the post, it's not that long

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.

git rebase -i kinda sucks once you tried jj.

Reply on news.ycombinator.com