Preserve children when reordering commits with conflicts

[anka-213]

If I reorder commits using rebase and get a conflict, I tend to need to resolve the conflict twice. Once for the moved commit and once again for the children. I would like a way to have the same file system state after reordering commits, so I don't need the second conflict resolution.

For example, after running jj rebase -r C -B B and resolving the conflicts in C', I want to restore so that the file system state after B' is the same as after C. What would be the best way to do this?

D      D
|      |
C      B'
|  =>  |
B      C'
|      |
A      A

Preferably I would like something at least semi-automatable, as if there are several commits with conflicts against the commit I move backwards, I would have to move the commit one commit at a time in order to localize the conflicts and resolutions. If there is a way to avoid manually moving the commit one step at a time, while still localizing/automatically resolving descendant conflicts by restoring files, I would also appreciate this.

D      C      C''
|      |      |
C      D'     B''
|  =>  |  =>  |
B      B      D''
|      |      |
A      A      A

[martinvonz]

#6141 will make the single-step case simpler. For the general case, I can't think of a better way than somehow finding the conflict-free state you at the end of the stack of commits before the reordering. You can find that using jj evolog, or you can of course save it somewhere before you start (e.g. in terminal scrollback).

[anka-213]

Thanks!

Re: # 6141, how would I use squash to reorder commits? No, you would use it to resolve conflicts, not to rebase.

I feel like I would want a rebase --restore-descendant, but that's rebase's default behaviour when there are no conflicts, so maybe that would be redundant. But maybe it would actually be a sensible option, where it would remove the conflicts from the descendant, by resolving them to be the file state from before the rebase? I'm not sure what would happen when you resolve those conflicts though?

---

Edit: After making a small test, this already seems to be the default behavior. Only the earlier commit has a conflict, but resolving the conflict introduces new conflicts in the descendants, so now I think I get your point about jj squash --restore-descendants, as when you resolve the conflict, you would normally use squash. I have been using jj resolve directly, so I guess for that I would also want to have a jj resolve --restore-descendants

[anka-213]

Here's an attempt at automating the jj evolog step:

j restore --from $(jj evolog -r 'roots(conflicts())' -T 'self.commit_id() ++ "\n"' --no-graph | head -n2 | tail -n1) --into 'roots(conflicts())'

The state before resolving the conflict should be the same state as before the reordering