Comment by aidos
7 hours ago
Can you explain how conflicts are not conflicts?
If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?
7 hours ago
Can you explain how conflicts are not conflicts?
If I change a line of code several times and rebase on to a branch that changed the same lines of code, how are you sure what the right one is?
JJ can save conflict related state with the change so that you don't need to resolve a conflict in the middle of a stack of changes for rebasing to continue for the remaining changes. Concretely, it uses a "conflict algebra" where it can track the impact of a conflict as it propagates through the stack of rebased changes: https://docs.jj-vcs.dev/latest/technical/conflicts/
That sounds like https://git-scm.com/book/en/v2/Git-Tools-Rerere ?
Not really very similar at all for the scenario discussed here. Rerere remembers how you have resolved a conflict before. It doesn't let you rebase a stack of commits that result in different conflicts. You will have to stop and resolve each conflict and then `git rebase --continue`.
However, the conflict algebra does remove many common uses of rerere. See https://github.com/jj-vcs/jj/issues/175#issuecomment-1079831... for a longer discussion.