[thecupisblue]

Yes, but in that case, I want the fix of the original mistake to be done in a new commit.

Why?

Example #1: - I am working on implementing API calls in the client, made 3 commits and opened a PR - In the meantime, the BE team decides they screwed up and need to update the spec

If I now go and fix it in the commit #1, I lose data. I both lose the version where the API call is in its original state, and I lose the data on what really happened, pretending everything is okay.

Example #2: - I am writing a JVM implementation for our smart-lens - In commit #2 I wrongly implement something, let's say garbage collection, and I release variables after they have 2 references due to a bug. - I am now 6 commits ahead and realise "oh shit wait I have a bug"

If I edit it inline in commit #2, I lose all the knowledge of what the bug was, what the fix is, what even happened or that there was a bug.

tldr: just do an interactive rebase

[phatskat]

From what I understand of how jj works, and I’m happy to be corrected because I’m still learning it, is that going back and editing those commits doesn’t change actual original “change” - that is, jj tracks a change ID to everything, and those original commits (once pushed) are immutable. So in theory, with jj, you should be able to see the original commit and the change to fix it, and you can still couple them into a single commit without losing that change history.