[anentropic]

If other systems are doing it too then I guess it must be useful

But why is it useful to be able to defer conflict resolution?

I saw in a parallel comment thread people discussing merge commit vs rebase workflow - rebase gives cleaner git history but is a massive pain having to resolve conflicts on every commit since current branch diverged instead of just once on the final result with merge commit.

Is it that? Deferred conflict resolution allows you to rebase but only resolve conflicts at the end?

[shaftway]

Delayed conflict resolution in jj is valuable when you're rebasing a long chain of commits. If I rebase a chain of 10 commits and each of the commits has a conflict, I'm stuck in conflict resolution mode until I fix all 10 conflicts. Maybe something else came up, or maybe I got tired of doing conflict resolution and want to do something else. Git's answer is to finish or abandon.

Also, in jj it's pretty easy to rebase a lot of stuff all at once, giving you even more opportunities to create conflicts. Being able to delay resolution can be easier.

[tcoff91]

Deferred conflict resolution is amazing in jj because I may never return to some of the branches that are in conflict and therefore might never bother resolving them.

I rebase entire trees of commits onto main daily. I work on top of a dev-base commit and it has all kinds of anonymous branches off it. I rebase it and all its subbranches in 1 command and some of those sub branches might now be in a conflicted state. I don’t have to resolve them until I need to actually use those commits.

dev-base is an octopus merge of in-flight PRs of mine. When work is ready to be submitted it moves from being a descendent of dev-base to a parent of dev-base.

Rebasing all my PRs and dev-base and all its descendents is 1 command. Just make sure my @ is a descendent of dev-base and then run: jj rebase -d main