Comment by yegle
12 hours ago
A term coined within Google that describes the best part (to me at least) of jj: delayed conflict resolution.
You worked on multiple things, you sync with the upstream, then boom now you have conflicts in one or more of your local branches.
Instead of immediately presenting you a conflict resolution view (usually 3 pane vimdiff) and you'll have to resolve at the sync time, the commits are simply marked as "have conflict", and you can continue working on other things until you have time to deal with it.
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.
> 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?
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?
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.
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.