Untracking a file in the past with edits in latter commits produces errorring conflicted commits

[necauqua]

Description

When you add a file in some commit, edit it in some latter commit (in my case unintentionally, it was an IDE config that was auto-tracked and I forgot to gitignore it), and then try to edit the commit that added it to untrack it (add to gitignore and jj untrack) - latter commits that had edits to that file are then conflicted, but if you try to edit them you get this (newlines added after colons):

Internal error:
Failed to check out commit <hash>:
Failed to open file <file you untracked> for writing:
Os { code: 17, kind: AlreadyExists, message: "File exists" }

Steps to Reproduce the Problem

Here is a reproduction I've built:

jj init --git
echo 'a' > a.txt
echo 'z' > z.txt
touch .gitignore
jj commit -m 'add a.txt'
echo 'b' > b.txt
echo 'zz' >> z.txt
jj commit -m 'add b.txt'
jj edit @--
echo 'z.txt' > .gitignore
jj untrack z.txt
# the @+ (add b.txt) is conflicted now
jj edit @+ # this prints an error
jj st # this errors saying wc is stale
jj workspace update-stale # same error as edit
rm z.txt
jj workspace update-stale # now it works, and (add b.txt) is still conflicted, but this time on deletion vs (echo 'zz' >> z.txt) of z.txt

Expected Behavior

So, from the point of view of jj it is deleted - the bug is that the actual file (from the current commit too) is left there since it was just untracked, and checking out the commit with delete-vs-change conflict while the file does physically exist unbeknownst to jj produces the file-already-exists error, that actually makes sense. Not sure what exactly the expected behavior should be.

Actual Behavior

It errors and you have to delete the file (backing it up somewhere else), resolve the conflicts by confirming deletion in every commit that edited the file, and then restore the file because you wanted it to be there, just untracked.

Specifications

• Platform: NixOS unstable
• Version: d4b13d7

[martinvonz]

The simplest solution would be to leave conflicting files in the working copy. That would make them appear as changed after the update. It would be good to collect a list of files we didn't update so we can tell the user that we left them unchanged. I think this is the solution you proposed.

Alternatively, we could check first and tell the user if there are any conflict. However, that would be racy and we might still discover conflicting files when we update, so I don't really like that solution.

[martinvonz]

I think that's pretty straight-forward to implement, if you or anyone else wants to, btw.

[yuja]

Maybe this is the same as a general un-ignored file conflicts? #778, #976

[martinvonz]

Thanks, I had forgotten that we already had bugs for this. #778 seems to be exactly the same.