3 ms·

If you're in the middle of a git rebase -i of a stack of 20 commits, and realize while editing commit 15 that you made a mistake at commit 8, how do you go back

If you're in the middle of a git rebase -i of a stack of 20 commits, and realize while editing commit 15 that you made a mistake at commit 8, how do you go back and edit commit 8 without having to complete the rebase -i? This is not contrived — this is an entirely realistic scenario that I use jj to handle all the time.

1718627440 1y ago
True nested rebase doesn't exist (yet) in Git. What I do is create another commit with the parent commit 8 with commit --fixup and then complete the rebase. The I can just autosquash it, without reediting anything. You could also keep the rebased commits, abort the rebase, rebase the already rebased commits and then continue the first rebase.
- sunshowers 1y ago
  With jj, because it doesn't have modal states of any kind, you can just go back to commit 8, edit it, and everything dependent on it gets auto-rebased. You can also do jj squash --into for a workflow similar to fixup commits. I would consider the first workflow to be impossible to do by most mere mortals in Git [1]. Meanwhile in jj it's downright trivial. [1] There technically is a way to do this by setting a temporary branch, aborting the rebase, starting another rebase -i, carefully editing the interactive instructions, going to commit 8, editing that commit, then cherry-picking 9-15 from the temporary branch. But it's too hard to do in practice, and far too easy to get wrong.
  - 1718627440 1y ago
    > [1] There technically is a way to do this That's what I've described? > rebase -i, carefully editing the interactive instructions You neither need to use interactive rebase nor carefully edit, since there is rebase --onto. > But it's too hard to do in practice, and far too easy to get wrong. I do this often it's not more complicated then any other rebase. What is annoying in Git is rebaseing across multiple merges while forging committer and date information. Can JJ do that better?
    - sunshowers 1y ago
      Ah I misinterpreted what "keep the rebase commits" meant. I'm glad you don't find it too difficult to do. It's a workflow that seemingly works well for you!

1718627440 1y ago

True nested rebase doesn't exist (yet) in Git. What I do is create another commit with the parent commit 8 with commit --fixup and then complete the rebase. The I can just autosquash it, without reediting anything. You could also keep the rebased commits, abort the rebase, rebase the already rebased commits and then continue the first rebase.

sunshowers 1y ago
With jj, because it doesn't have modal states of any kind, you can just go back to commit 8, edit it, and everything dependent on it gets auto-rebased. You can also do jj squash --into for a workflow similar to fixup commits. I would consider the first workflow to be impossible to do by most mere mortals in Git [1]. Meanwhile in jj it's downright trivial. [1] There technically is a way to do this by setting a temporary branch, aborting the rebase, starting another rebase -i, carefully editing the interactive instructions, going to commit 8, editing that commit, then cherry-picking 9-15 from the temporary branch. But it's too hard to do in practice, and far too easy to get wrong.
- 1718627440 1y ago
  > [1] There technically is a way to do this That's what I've described? > rebase -i, carefully editing the interactive instructions You neither need to use interactive rebase nor carefully edit, since there is rebase --onto. > But it's too hard to do in practice, and far too easy to get wrong. I do this often it's not more complicated then any other rebase. What is annoying in Git is rebaseing across multiple merges while forging committer and date information. Can JJ do that better?
  - sunshowers 1y ago
    Ah I misinterpreted what "keep the rebase commits" meant. I'm glad you don't find it too difficult to do. It's a workflow that seemingly works well for you!