> Ah, I see, so you avoid interactive rebase and instead make all changes in the working copy and use `git commit --fixup` and `git rebase -i .
I wouldn't say I avoid this, I also run `git rebase -i` several times per day, and I also often use `git commit --fixup` during a rebase.
> Makes sense, but doesn't it break down when there are conflicts between the changes you're making in the working copy and the target commit?
Yes, but wouldn't this be the same in JJ, when you do your changes on top of A, and later squash them into D? If you don't want to have the changes, you can also checkout D and do the changes there. Then you have two options:
- `git commit --fixup`, later do `git rebase`
- `git commit --amend`, and `git rebase --onto`
Most times I do the thing described earlier and just solve the conflicts, because that's just a single command. Also when its only a single case, I use `git stash`. (The workflow then is do random fix, git stash, then figure out where these should go, git rebase)
> How do you adjust the steps if there were conflicts between the changes we wanted to make to A and the changes already present in B?
I just resolve them? I think I don't understand this question.
