Don't break on stale workspace working copy

[YaLTeR]

If you have multiple jj workspaces and update one workspace's working copy through the second workspace (so the first one's goes stale), jj-fzf breaks:

└─ jj-fzf
+ jj --no-pager status
Error: The working copy is stale (not updated since operation 92b47ceb1a05).
Hint: Run `jj workspace update-stale` to update it.
See https://jj-vcs.github.io/jj/latest/working-copy/#stale-working-copy for more information.

It shouldn't break, instead it should probably prompt the user to run this command.

[tim-janik]

For background, jj-fzf will run jj st at startup to make sure the jj repo is in a usable state, other errors that might prevent it from working is e.g. if too big files cannot be auto-snapshot. It couldn't handle all possible error cases, but at least let the user know about it and not make matters worse.
Background for stale workspaces: https://jj-vcs.github.io/jj/latest/working-copy/#stale-working-copy

I don't think jj has a non-intrusive (--ignore-working-copy) command to ask if the working copy is stale. So we would have to start with error parsing upon jj status. Doable, but what is it good for?

• If jj st and other commands cannot be run without errors, it is not reasonable to expect jj-fzf to work.

• The docs read as if the situation can be "resolved" by simply running jj workspace update-stale. jj-fzf could do that automatically, but then, why doesn't jj status simply run update-stale and fix the situation?

I'd actually like to see a word from the jj project about whether automating jj workspace update-stale is a good idea or not.

[tim-janik]

JJ-0.24 has added 'snapshot.auto-update-stale' which might help with your situation:
https://github.com/jj-vcs/jj/blob/main/CHANGELOG.md#0240---2024-12-04

But there are also some usability issues reported with it: jj-vcs/jj#7229

Seeing the latter makes me think that jj-fzf better not try to automatically run update-stale.

In any case, it could only warn at startup anyways, editing the way we run other commands would be too intrusive. And since jj-fzf purposefully runs jj st as very first thing to make sure the repo is in a sane state, I think this should better become a bug report against jj st missing a:
Hint: you might want to set snapshot.auto-update-stale=true

About running a check at the time F5 is pressed in jj-fzf, we don't really have a good way to abort jj-fzf in that situation or generally start interactive error handling when we're just supposed to reload the jj log list.

[YaLTeR]

Hm, irrecoverable loss of working copy changes sounds quite bad..

[github-actions]

This issue is considered stale, because it has been open for several weeks with no activity.