Comment by drsouth
11 hours ago
> And for a chain of commits that all have conflicts, chances are fixing the first conflict automatically resolves all other conflicts in the chain, thanks to the auto-rebasing feature.
What happens if one is unlucky and the conflicts are not automatically resolved from changes to the first commit? Does that potentially imply more work overall than if one was using a VCS that forced conflict resolution earlier, like git?
It’s fundamentally no different than doing the same resolution in git.
The main advantages are that you can do the changes piecemeal, in any order, at any time, and by jumping around in the commit history however you need or want to.
Sometimes the best way to solve a conflict is by changing something before the conflict, or by moving pieces from one commit to another. Git doesn’t allow this, you can only do: fully fix commit 1, fully fix commit 2, fully fix commit 3, and so on.
No worries, it's still just another commit w/ conflict. If you want, solve those conflicts later.
Why is git's "forced conflict resolution" better, assuming the same workflow (local change+sync upstream) would produce the same # of conflicted commits?
git doesn't force conflict resolution earlier. It forces conflict resolution the moment you pull changes from upstream. jj allows you to go back to the first conflicting commit and then fix things there. That first conflicting commit is most likely a lot more similar to the upstream code than your newest commit and therefore it is easier to fix.