Working copy changes are lost when a remote branch is deleted and git fetch has run

[jennings]

Description

Suppose you're working in a colocated repo and:

• A remote branch has been deleted
• The working copy is one of the changes that were part of the deleted branch
• The working copy has been modified, but jj has not been run yet so no snapshot has been taken
• git fetch --prune is run (in my case, my editor periodically fetches)

Then, the edits in the working copy are lost when jj abandons the changes. The changes were never added to a snapshot, so they aren't available in the operation log.

Steps to Reproduce the Problem

Here is a script that reproduced the problem. The branch "feature" is the one to be deleted from the remote.

# SETUP: Create the upstream
mkdir repro-bug
cd repro-bug
git init --bare upstream.git
git init someone-elses-repo -b main
cd someone-elses-repo
echo "hello" > file
git add file
git commit -m "initial"
git remote add origin ../upstream.git
git push -u origin main

# SETUP: Create a side branch
git checkout -b feature
echo "goodbye" >> file
git commit -am "change file"
git push -u origin feature
cd ..

# Create the local repo and edit the tip of the branch "feature"
jj git clone --colocate upstream.git local
cd local
jj branch track feature@origin
jj edit feature

# Delete the branch from the remote
cd ../someone-elses-repo
git push origin :feature
cd ../local

# Edit the working copy and git fetch
echo "hello again" > file
# I need this because git doesn't understand \\?\ paths on Windows
# git remote set-url origin ../upstream.git
git fetch
# git remote set-url origin '\\?\C:\Users\StephenJennings\repro-bug\upstream.git'
jj

Expected Behavior

The working copy still contains "hello again" in file.

Actual Behavior

The working copy contains only "hello" and no change contains "hello again".

Specifications

• Platform: Windows
• Version: 0.13.0

[ilyagr]

Do I understand correctly that your modifications are still there after the "git fetch" (penultimate command in your demo), but jj discards them?

[jennings]

Yes, I’m not sure how they would be removed at that point since git fetch doesn’t modify the working copy, just the object store and remote tracking refs.

My hypothesis is that the automatic jj git import is happening before a snapshot would, so jj never learns about the modified working copy. Then it abandons the changes that were in the deleted branch and overwrites the files on disk with whatever @ moves to.

[jennings]

Thinking about it more, I can probably simplify the reproduction by removing the remote. I’m guessing that deleting a local git branch then running jj would trigger the same thing.

[yuja]

the automatic jj git import is happening before a snapshot would,

Correct, and jj would probably think the HEAD was moved externally (so reset the working copy.) Perhaps, maybe_snapshot() will have to do

1. handle externally moved HEAD
2. snapshot
3. import refs

[yuja]

simplify the reproduction by removing the remote

git init repo
cd repo
jj init --git-repo=.
echo 1 > file
jj branch create feature
git branch -D feature
echo 2 > file
jj status
cat file

btw, the original repro script needs git fetch --prune.

[jennings]

Ah, great, that’s much easier to understand. When it happened to me, VSCode had done the fetch so I wrote the reproduction as similar as I could to my real situation.

btw, the original repro script needs git fetch --prune.

You’re right, I forgot that I have automatic prune enabled.