`--at-op` from before `jj workspace rename` writes git HEAD, bringing back a rewritten commit

Open

bosopened 5d ago

Description

In a colocated repository, a command run with --at-op at an operation from before the current workspace was renamed still sets git's HEAD, without the stale-working-copy check jj makes otherwise.

The next command imports HEAD and moves the working copy onto it, bringing back a commit that has been rewritten since, so its change is divergent. Without the rename, the next command instead says the working copy is stale.

Steps to Reproduce the Problem

jj git init --colocate repo && cd repo
echo 1 > a && jj commit -m A
jj new --no-edit 'root()' -m X
X=$(jj log --no-graph -r 'description(exact:"X\n")' -T commit_id)
op=$(jj op log --no-graph -n1 -T id)
jj describe "$X" -m X2
jj workspace rename work
jj --at-op "$op" new "$X"     # concurrent with the describe and the rename
git rev-parse HEAD            # X: the stale command wrote HEAD
jj status
jj log -r 'all()' -T 'commit_id.short() ++ " " ++ description.first_line() ++ "\n"'

Expected Behavior

As without jj workspace rename: the stale command doesn't move the working copy, the next command says it is stale, and X stays rewritten as X2.

Actual Behavior

Concurrent modification detected, resolving automatically.
Rebased 1 descendant commits onto commits rewritten by other operation.
Reset the working copy parent to the new Git HEAD.
Working copy changes:
A a
Working copy  (@) : upqstyrl fc87e6f9 (no description set)
Parent commit (@-): rxxkuwwt/1 1028758e (divergent) (empty) X
@  fc87e6f9692c
○  1028758efc34 X
│ ○  27f8edee4031
│ ○  eefad8cc8a02 X2
├─╯
│ ○  8bfb7f658d84 A
├─╯
◆  000000000000

Specifications

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

Activity

yuja5d ago

Perhaps --at-op=<non-head> should disable Git import/export entirely because the external Git state should be kept in sync with the operation head. I suspect there are various things that need to be fixed first, though.