Concurrent op loses an empty working-copy commit that `jj workspace forget` abandons

Open

bosopened 5d ago

Description

When jj workspace forget abandons a workspace's empty working-copy commit W, a concurrent operation that points a bookmark at W, or creates a commit on W, loses W on merge: the bookmark moves to W's parent and the new commit is rebased onto it. Run one after the other, in either order, both keep W (the bookmark stays on W and the new commit's parent is W), so the merge matches neither order. The forget abandons W only as cleanup, so it seems the concurrent use of W should keep it, as either order does.

Steps to Reproduce the Problem

jj git init repo && cd repo
jj describe -m P
jj workspace add --name other -r @ ../other   # other@ is W, empty, on P
W=$(jj log --no-graph -r other@ -T commit_id)
op=$(jj op log --no-graph -n1 -T id)
jj workspace forget other                     # abandons W
jj --at-op "$op" bookmark set topic -r "$W"   # concurrent with the forget
jj --at-op "$op" new --no-edit -m child "$W"  # likewise
jj log -r 'all()' -T 'commit_id.short() ++ " " ++ description.first_line() ++ " " ++ local_bookmarks.map(|b| b.name()).join(" ") ++ "\n"'

Expected Behavior

topic points at W, and child's parent is W, which stays visible.

Actual Behavior

Concurrent modification detected, resolving automatically.
Rebased 1 descendant commits onto commits rewritten by other operation.
○  872efeb7f3bd child
@  ee806cbea1f4 P topic
◆  000000000000

Specifications

Platform: Linux
Version: jj 0.46.0, and main at b8c328b

Activity

No activity yet.