Prevent jj undo from restoring to root operation

[murataslan1]

Summary

This fixes #8153 by preventing jj undo from restoring to the root operation, which would leave the repo in an unusable state with no working copy.

Changes

• Added a check in cmd_undo to detect when op_to_restore is the root operation (has no parents)
• Returns a helpful error with a hint to use jj redo if the user has undone too far
• Updated the test to reflect the new behavior

Before

$ jj git init
$ jj undo
Restored to operation: 000000000000 root()
$ jj new
Error: This command requires a working copy

After

$ jj git init
$ jj undo
Error: Cannot restore to root operation
Hint: Use `jj redo` to move forward if you have already undone too far

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[github-actions]

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

• 3ce8fa4: Prevent jj undo from restoring to root operation

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

[martinvonz]

I would rather print a hint saying that the workspace was removed and how to restore it. This would not be specific to the root operation.

[murataslan1]

Thanks for the feedback @martinvonz!

I understand you'd prefer a hint when the workspace is removed rather than blocking the operation. Could you clarify the approach?

Should the hint be shown:

1. After a successful restore when the current workspace no longer exists in the restored view?
2. Something like: Hint: Workspace 'default' was removed by this operation. Use 'jj workspace add' to create a new one, or 'jj redo' to restore the previous state.

I'll update the implementation accordingly.

[martinvonz]

Yes, that sounds about right. I think you can implement it around here:

jj/cli/src/cli_util.rs

Lines 2172 to 2173 in a1c9c3d

	// It seems the workspace was deleted, so we shouldn't try to
	// update it.

I'm not sure if we'll want to show the hint even if may_update_working_copy is false (e.g. with --ignore-working-copy). Unless someone has an opinion, I would probably just go with not printing the hint in that case.

Regarding the wording in the hint, the jj redo suggestion will not work if the workspace was deleted because the user did jj op restore, so perhaps it's best to suggest jj op revert.

Thanks!

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