So... git rebase -i?

▲ idoubtit an hour ago | parent | next [-]

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 25 minutes ago \| parent [-]
		But isn't the flow nearly identical with jj, because the key part, the moving of hunks, is interactive (aka manual) anyway?

▲ nomel 2 hours ago | parent | prev | next [-]

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

▲

ahepp an hour ago | parent | next [-]

> 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 22 minutes ago \| parent [-]
		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.

▲

2 hours ago | parent | prev [-]

[deleted]

▲ 9029 2 hours ago | parent | prev | next [-]

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

	▲	raincole an hour ago \| parent [-]
		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.

▲ ai_slop_hater 2 hours ago | parent | prev [-]

git rebase -i kinda sucks once you tried jj.