Undoing `jj workspace rename` leaves the renamed workspace with "No working copy"

Open

bosopened 6d ago

Description

If a workspace is renamed and the rename is then undone with jj undo --allow-cross-workspace, jj op restore, or jj op revert, the repo view gets the old name back. The renamed workspace's own working copy still says it's the new name, though, so it no longer matches any workspace in the view. jj status there prints "No working copy.", and neither jj workspace update-stale nor jj workspace rename can repair it.

Steps to Reproduce the Problem

jj git init main
cd main
jj workspace add --name second ../secondary
cd ../secondary
jj workspace rename third
cd ../main
jj undo --allow-cross-workspace   # or: jj op restore @-   or: jj op revert
jj workspace list
cd ../secondary
jj status
jj workspace update-stale
jj workspace rename second

Expected Behavior

The workspace in ../secondary stays usable after the undo, under whichever name.

Actual Behavior

$ jj undo --allow-cross-workspace
Undid operation: 70563c7a2160 (2026-10-24 16:38:51) Renamed workspace 'second' to 'third'
Restored to operation: 26c22e1c14ec (2026-10-24 16:38:50) create initial working-copy commit in workspace second

$ jj workspace list
default: . mqwrswum 9bcc5f3f (empty) (no description set)
second: xzwqnvkl ad12599e (empty) (no description set)

$ cd ../secondary
$ jj status
No working copy.

$ jj workspace update-stale
Error: Nothing checked out in this workspace

$ jj workspace rename second
Error: The current workspace 'third' is not tracked in the repo.

jj op restore @- and jj op revert give the same result. second also shows no path in jj workspace list, because the rename moved the workspace store's entry to third.

The only recovery I found is to redo the rename from another workspace (jj redo, or restoring the rename operation).

A plain jj undo in the renamed workspace itself refuses, because the rename operation was recorded under the old name:

$ jj undo
Error: Refusing to undo operation 76f67fd68fd4 because it was performed in workspace second
Hint: Use `--allow-cross-workspace` to undo it anyway, or use `jj op revert` to revert a specific operation

Specifications

Platform: macOS
Version: jj 0.46.0

Activity

yuja5d ago

We have a warning for undoing workspace remove. We should probably add a similar warning for workspace rename as well.

bos5d ago

Agreed. While looking at where to put it, I found that the problem is a bit wider than jj undo of a rename, so I'd like to check the scope with you before writing the PR.

jj op restore and jj op revert break the renamed workspace the same way, and neither prints the existing workspace remove warning either, since that check only exists in jj undo.

Undoing jj workspace add has the same failure: after jj op restore to before the add, the added directory reports "No working copy." and jj workspace update-stale fails with "Nothing checked out in this workspace". And jj op restore over a workspace remove brings the workspace back with no path, without a warning.

In every case, the view's workspace names get restored, but the working copy's own name and the workspace store's entries don't. Since undo, restore, and revert all build the new view through view_with_desired_portions_restored(), I'd do the check there by comparing workspace names between the current view and the new view, instead of matching on the op description:

A workspace name that comes back without a usable directory (undoing a remove, or the old name after undoing a rename): keep today's warning and hint, but now from all three commands. This replaces the starts_with("remove workspace") check.
A workspace name that disappears while its directory still exists (undoing an add or a rename): warn that the workspace at that path will report "No working copy", with a hint to undo this operation right away.

I'd leave an actual fix out of scope, such as rewriting the other workspace's working-copy name or store entry during the restore, or making update-stale able to recover. Does that sound right?

yuja5d ago

I think it's fine and simple to emit warnings based on the op description. While I'm not opposed to comparing views, we shouldn't rely on the disk state. A workspace may be temporarily unavailable.

jj op restore is an expert command. A friendly warning isn't required.