Make other working copies immutable #4421
Conversation
It's come up a few times that people want to mark working copies other than the current one as immutable. We don't have a way of finding such commits. `working_copies() ~ @` is close, but it's not correct if the same commit is being edited in the current workspace and in another workspace. This patch adds a `other_working_copies()` revset for it.
This should avoid other workspaces going stale most of the time. Also include all working copies in default log since we would otherwise hide other working copies now.
martinvonz
force-pushed
the
push-prpmnoxnwrxm
branch
from
eebd857
to
61339c0
Compare
There was a problem hiding this comment.
working_copies() ~ @is close, but it's not correct if the
same commit is being edited in the current workspace and in another
workspace.
Wouldn't it simpler to allow mutation in that case? If the wc commit is already editing, I wouldn't expect it to become immutable by editing the exact commit in other workspace.
There was a problem hiding this comment.
It certainly would be simpler, but I think it seems more correct. Since the goal is to avoid accidentally creating stale workspaces, we should avoid that also if another workspace is editing the same commit (or a descendant).
There's also not currently a way to correctly calculate the set of commits edited in other workspaces, but maybe that doesn't really matter if we ignore this use case (i.e., I haven't thought of other use cases).
There was a problem hiding this comment.
Since the goal is to avoid accidentally creating stale workspaces, we should avoid that also if another workspace is editing the same commit (or a descendant).
That's correct, but in order to edit the same commit, the user would have to use --ignore-immutable edit in another workspace, so I (as a user) wouldn't mind if it made the other workspace ignore immutability of the wc commit. (There might be other ways to enter such situation, but that's rare?)
There was a problem hiding this comment.
It could also happen if you do jj edit <parent> in one workspace and jj edit <child> in another workspace. Going back to the first workspace would then result in it becoming immutable. That seems consistent to me. However, since we don't prevent snapshotting even if the commit is immutable, it's already not going to work very well for preventing stale workspaces in that case, so I think it makes sense to simply add working_copies() ~ @ as I think you're suggesting. I'll update this PR to do just that.
I'm a bit uneasy about this because of the test changes in the last commit. It's clearly a corner case there (undoing
jj workspace forgetcausing some commits to become immutable), but there may be similar cases. I was wondering if we should create the new working-copy commits when snapshotting instead. I thought we had talked about that in the context of #3201 but I don't see any mention of it there. Maybe we talked about it on Discord. Anyone remembers?Checklist
If applicable:
CHANGELOG.md