squash: support --restore-descendants

[LoganDark]

Sometimes it is convenient to be able to make changes to a commit in the past without affecting descendants -- I already have a workflow that tracks the commits of all children, makes the changes, and then restores manually, but that performs a lot more rebases than necessary, which adds up when history is long. Supporting --restore-descendants for jj squash helps this workflow greatly.

Checklist

If applicable:

• I have updated CHANGELOG.md
• I have updated the documentation (README.md, docs/, demos/)
• I have updated the config schema (cli/src/config-schema.json)
• I have added/updated tests to cover my changes
• I fully understand the code that I am submitting (what it does,
  how it works, how it's organized), including any code drafted by an LLM.
• For any prose generated by an LLM, I have proof-read and copy-edited with
  an eye towards deleting anything that is irrelevant, clarifying anything
  that is confusing, and adding details that are relevant. This includes,
  for example, commit descriptions, PR descriptions, and code comments.

Prior Art

I found #6141 but haven't looked too far into it.

[github-actions]

The following commits do not follow our format for subject lines:

• 72f1215: support --restore-descendants for squash

Commits should have a subject line following the format <topic>: <description>. Please review the commit guidelines for more information.

[PhilipMetzger]

Please move the motivation from the PR into the commit description to adhere to our commit style. Also adjust the topic like the bot suggests.

[LoganDark]

Please move the motivation from the PR into the commit description to adhere to our commit style. Also adjust the topic like the bot suggests.

Sorry, internet went out. Working on it now.

All commits are now correctly formatted. Thank you for your contribution!

[PhilipMetzger]

lgtm, still needs maintainer approval though

[josephlou5]

Following https://docs.jj-vcs.dev/latest/contributing/#commit-guidelines, maybe the topic of the commit subject should be squash: instead of `jj squash`:?

Also, there is a missing backtick after `--restore-descendants in the second to last line.

[LoganDark]

Following https://docs.jj-vcs.dev/latest/contributing/#commit-guidelines, maybe the topic of the commit subject should be squash: instead of `jj squash`:?

Oops, didn't notice that part of the page. (I was there.)

Also, there is a missing backtick after `--restore-descendants in the second to last line.

Fixed as well.

[martinvonz]

I found #6141 but haven't looked too far into it.

I think it's worth doing that so we don't need to rehash the same things here.

[LoganDark]

I found #6141 but haven't looked too far into it.

I think it's worth doing that so we don't need to rehash the same things here.

My implementation differs, so it's not trivial to translate the feedback. I can't reproduce the bugs mentioned in the discussions there. Conflicts work correctly if you squash to a destination where the diff doesn't apply cleanly, the flag works in combination with -A/-B, nothing weird happens when the squash source has descendants, etc. No need to disallow anything. I would really prefer some individual feedback.

The only thing that seems potentially relevant is partial squashing into ancestors, but with my implementation that moves the change to exclusively that ancestor and correctly propagates the lack of it to descendants, so I don't see an issue there either. Everything seems to be fairly obvious and there don't seem to be any unintuitive edge cases that I can tell.

[martinvonz]

@ilyagr: Any chance you can review this PR?

[LoganDark]

rebased onto the latest master. (or "main")

Do we know if a review is likely to happen?

[PhilipMetzger]

I'd really like this or #6141 to land, since I've now repeatedly hit cases where it is extremely useful.

[jennings]

I did not review the implementation, but the tests seem to show a reasonable behavior. I just added some suggestions for making the tests easier to show how the graph changes.