Rebasing commit with files that is "unignored" in new parent "trashes" working copy

[tp-woven]

Description

After fetching a commit that removes BUILD.bazel from .gitignore and adds files, I tried rebasing an older branch on top of it (while having "local" versions of the "unignored" files), causing BUG: Working copy lock was dropped without being closed.

Related Discord conversation: https://discord.com/channels/968932220549103686/969829516539228222/1044444142379475095

Steps to Reproduce the Problem

1. Two commits: Commit A has foo in .gitignore and a file called foo. Commit B removes foo from .gitignore and adds a new file foo.
2. Rebase A onto B

Expected Behavior

Not sure, divergence? Conflict marker? Overwrite foo with the contents in commit B?

Actual Behavior

❯ jj sync
Rebased 1 commits
BUG: Working copy lock was dropped without being closed.
Internal error: Failed to check out commit de915aec81c298130c8b18641a46a93620dd9026: Failed to open file /.../BUILD.bazel for writing: Os { code: 17, kind: AlreadyExists, message: "File exists" }

And repo becomes unusable until the situation is recovered.

[OGKevin]

How do you "recover" the repo at this point?

 jj edit yw
BUG: Working copy lock was dropped without being closed.
Internal error: Failed to check out commit 8e43593bb82f1d264a666059552c3022a13a34a5: Failed to open file */enum_enum.go for writing: Os { code: 17, kind: AlreadyExists, message: "File exists" }

and now im repo is broken,

❯ jj workspace update-stale
Error: The working copy is stale (not updated since operation e31b682345b0).
Hint: Run `jj workspace update-stale` to update it.
See https://github.com/martinvonz/jj/blob/main/docs/working-copy.md#stale-working-copy for more information.

edit: I just used git directly to alter the workspace, after changing commits, I was able to use jj again.

[martinvonz]

Sorry about the bug. Maybe it was a version of #976 (i.e. an issue with updating from a commit where a file is ignored to a commit where the file exists). I'm glad you found a workaround at least.

[landtuna]

I think I just hit this one, too. Steps:

• initialized a new jj repo from an existing git repo
• got error message about a file that was too big in my workspace (had been untracked by git)
• rm -rf .jj
• added file to .gitignore
• jj init --git-repo .
• did some work
• jj checkout some_other_branch

BUG: Working copy lock was dropped without being closed.
Internal error: Failed to snapshot the working copy: New file <my file> of size ~1.2MiB exceeds snapshot.max-new-file-size (1.0MiB)

I moved the offending file, and everything seems okay...

[martinvonz]

@landtuna: I'm sorry about the bug. We have talked about adding some kind of temporary ignores to handle that case but I can't find the discussion now (@ilyagr, do you remember where we talked about it?). The idea is that we'd notice when we update from one commit to another if any .gitignores changed. If they did, we'd add matching paths to an additional list of files to ignore. It seems like that would work.

[ilyagr]

@ilyagr, do you remember where we talked about it?

Found it: #323 (comment). Perhaps that should be a duplicate of this one (or vice-versa)?

[martinvonz]

Found it: #323 (comment).

Thanks!

Perhaps that should be a duplicate of this one (or vice-versa)?

I see that bug mostly as a feature request for turning off the auto-tracking. #976 sounds like a duplicate of this bug (feel free to close that one if you agree). I guess we don't have one that I would consider the canonical bug for the "temporary ignores" feature we're talking about here.

[martinvonz]

As noted above, this seems like a duplicate of #976 (which is now fixed).