cargo 1.86 package (and publish) fail when workspace crate contains symlink into git submodule

[e00E]

I've attached a minimal reproduction cargo-bug-test.zip. Download it and run the following commands.

1. unzip cargo-bug-test.zip
2. cd cargo-bug-test
3. git status

Verify that git status reports a clean directory. If not, then extracting the symlink out of the zip didnt' work. This might happen on Windows. I've only tested on Linux.

The folder structure looks like this:

.git/...
Cargo.lock
Cargo.toml
crates/
crates/workspace-crate/
crates/workspace-crate/Cargo.lock
crates/workspace-crate/Cargo.toml
crates/workspace-crate/link-into-submodule -> ../../the-submodule/submodule-file
crates/workspace-crate/src/
crates/workspace-crate/src/lib.rs
the-submodule/
the-submodule/.git/...
the-submodule/submodule-file

Note that there is a git repository at the root and in the-submodule. This makes the-submodule a submodule, even though it isn't specified by a git URL. I did it this way to get a self contained example. Usually you would have a submodule with URL. The bug is the same.

cargo +1.85 package -p workspace-crate succeeds.

cargo +1.86 package -p workspace-crate fails with this error:

error: attempt to get status of nonexistent file 'the-submodule/submodule-file'; class=Invalid (3); code=NotFound (-3)

The change behavior is caused by #14981 . The call repo.status_file(&rel_path) returns the error we see in the command line output. This could be a bug in Git2 or it could be that Cargo shouldn't pass submodule paths into Git2.

[weihanglo]

Yeah this is a regression. Would you mind copying the reproducible example and adding a comment to #15384, and we close this as a duplicate?