cli: hint at recovered changes after `workspace update-stale` by joshka · Pull Request #9786 · jj-vcs/jj

joshka · 2026-07-08T12:39:35Z

Problem

When jj workspace update-stale resets a stale working copy, it first snapshots any un-snapshotted on-disk changes into a commit, then checks out the fresh commit — overwriting those changes on disk. The only output names the fresh commit, so the update looks like data loss even though the changes were preserved and are recoverable:

$ jj workspace update-stale
...
Updated working copy to fresh commit 90f3d42e0bff

This has confused several users (e.g. #7229, and reports on Discord). jj undo doesn't help here either, because update-stale ends on a reconcile/merge operation (Error: Cannot undo a merge operation), so the command's own output is the only reasonable place to surface the recovery path.

Change

When the pre-update snapshot actually preserved un-snapshotted changes, print a hint naming the commit they were saved in and the jj restore to get them back:

Updated working copy to fresh commit 90f3d42e0bff
Hint: Working-copy changes were saved in commit 5f9e41510c33.
Restore them with `jj restore --from 5f9e41510c33`.

Only fires when the pre-update snapshot amended the working-copy commit (i.e. there were un-snapshotted changes that got overwritten) — no output in the clean case.
The lost-operation recovery path already prints a labeled RECOVERY COMMIT FROM ... explanation; this gives the far more common normal path the same legibility.

Tests

New test_workspaces_update_stale_recovers_changes: makes a workspace stale with an un-snapshotted edit, runs jj workspace update-stale, asserts the hint, then runs the exact jj restore --from <hinted commit> and asserts the edit is recovered — a full round-trip.
Updated the two existing snapshots that hit this path (explicit update-stale, and the auto-update-stale case). The clean-stale and "attempted recovery, but not stale" tests are unchanged, pinning the gating.
Full jj-cli suite passes; cargo fmt clean.

Addresses the confusion reported in #7229.

PhilipMetzger

LG with minor nits. I guess Joseph will also chime in with some wording fixes.

PhilipMetzger · 2026-07-08T15:33:31Z

+                                "Uncommitted changes were saved in commit {} before the working \
+                                 copy was updated.\nRestore them with `jj restore --from {}`.",


nit: indoc seems useful here instead of manually inserting newlines and stuff.

Done — now uses writedoc! with an inline {stale_commit} capture, so there are no manual \ns or \ line-continuations.

PhilipMetzger · 2026-07-08T15:35:38Z

+* When `jj workspace update-stale` resets a working copy that had un-snapshotted
+  changes, it now prints a hint naming the commit those changes were saved in and
+  the `jj restore` command to recover them, so the update no longer looks like
+  data loss. Disable with `hints.recovered-changes = false`.


nit: This is extremely wordy for no good reason. Also this is missing a Issue link.

"When jj workspace update-stale resets a working copy with unsnapshotted changes it now provides a hint on how to recover these changes.

Trimmed to one line and added the #7229 link.

PhilipMetzger · 2026-07-08T15:36:09Z

@@ -1,2 +1,3 @@
 [hints]
 resolving-conflicts = true
+recovered-changes = true


nit: I don't think we should add this option to this table until people complain.

Removed — reverted hints.toml.

PhilipMetzger · 2026-07-08T15:36:40Z

+                        // overwrote them on disk. Point the user at that commit so the
+                        // update doesn't look like data loss.
+                        if recovered_local_changes
+                            && self.settings().get_bool("hints.recovered-changes")?


ditto, its to early to provide an option for that.

Dropped the config gate; the hint is unconditional now (shown only when the recovery actually preserved changes).

PhilipMetzger · 2026-07-08T15:37:56Z

I also think this addresses the mentioned issue.

joshka · 2026-07-13T00:30:18Z

Thanks for the review! Addressed all four nits in the latest push:

writedoc! + inline {stale_commit} (no manual newlines)
dropped the hints.recovered-changes gate and its hints.toml entry
trimmed the changelog + linked jj workspace update-stale destroyed all changes in the workspace #7229

Also took a small pass on the hint wording and the code comment, and rebased onto current main (picking up the trailing-period logging change, which is why CI re-ran). Happy to adjust the wording further based on Joseph's suggestions.

joshka · 2026-07-13T00:42:26Z

A broader thought this message surfaces — not all of which belongs in the hint itself, but it frames why the wording matters here.

This fires at a genuinely high-stress moment. update-stale rewrites files in the working directory, so from the user's side, source they were editing just changed or disappeared — which reads as data loss on its own. It's compounded by a second hazard: those on-disk rewrites can collide with unsaved editor state — a buffer with newer edits, or an editor showing a file that was rewritten underneath it. So there are several avenues for confusion and recovery, not just one.

The user is also pushed down this path fairly blind. The upstream stale error —

Error: The working copy is stale (not updated since operation 17d05d75464f).
Hint: Run `jj workspace update-stale` to update it.

— doesn't mention that running update-stale will modify files in the working copy, so it's run without knowing on-disk edits are about to be touched. And update-stale's own output —

Rebased 1 descendant commits onto commits rewritten by other operation
Working copy  (@) now at: ypwkwnqk/2 e881a488 (divergent) (empty) ...
Added 1 files, modified 0 files, removed 1 files
Updated working copy to fresh commit e881a488dad2

— is cryptic about what became of the user's actual source (the (divergent) (empty), the file counts). This PR's hint is one small step, but the whole flow (stale error → update-stale output) is really an opportunity to teach how this affects the user's working copy.

Given that, this feels like one of the few jj messages where a reassurance-first phrasing is worth considering, e.g.:

Hint: Your working-copy changes weren't lost — they were saved in commit e881a488.
Restore them with `jj restore --from e881a488`.

Happy to keep the terse version for house-style consistency — mostly flagging that the emotional context here is unusually high for a hint, and that the surrounding flow (especially the stale error not warning that files will change) might merit its own follow-up. Curious what you and @josephlou5 think.

josephlou5 · 2026-07-13T01:18:52Z

Haha funny to see that I was mentioned for wording :p Seems mostly fine to me, though I have never used jj workspace commands so the use cases and the desired information at such times are a little fuzzy to me.

Also the commit description (and PR description too) are outdated after recent changes I think.

`jj workspace update-stale` snapshots any un-snapshotted changes in the stale working copy before it checks out the fresh commit and overwrites them on disk. Since the only output named the fresh commit, the update looked like data loss even though the changes were preserved and recoverable. When the pre-update snapshot preserved such changes, print a hint naming the commit they were saved in and the `jj restore --from <commit>` to recover them. The lost-operation recovery path already prints a similar explanation; this gives the far more common path the same legibility. Addresses jj-vcs#7229.

joshka · 2026-07-13T02:20:29Z

Good catch, thanks — updated both the commit and PR descriptions to drop the config-gate mention (removed in the earlier round) and match the current wording.

joshka requested a review from a team as a code owner July 8, 2026 12:39

PhilipMetzger reviewed Jul 8, 2026

View reviewed changes

joshka force-pushed the update-stale-recovered-changes-hint branch 4 times, most recently from fc94b49 to 6d3008a Compare July 13, 2026 00:13

joshka force-pushed the update-stale-recovered-changes-hint branch from 6d3008a to d585f17 Compare July 13, 2026 01:49

joshka mentioned this pull request Jul 13, 2026

docs(orchestration): fix update-stale misstatement (README guidance already landed via T5) joshka/qwertty-term#121

Merged

		"Uncommitted changes were saved in commit {} before the working \
		copy was updated.\nRestore them with `jj restore --from {}`.",

Uh oh!

Conversation

joshka commented Jul 8, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Change

Tests

Uh oh!

PhilipMetzger left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

PhilipMetzger commented Jul 8, 2026

Uh oh!

joshka commented Jul 13, 2026

Uh oh!

joshka commented Jul 13, 2026

Uh oh!

josephlou5 commented Jul 13, 2026

Uh oh!

joshka commented Jul 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

joshka commented Jul 8, 2026 •

edited

Loading