Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
e00E opened this issue Apr 10, 2025 · 1 comment · Fixed by #15416
Closed

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

e00E opened this issue Apr 10, 2025 · 1 comment · Fixed by #15416
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@e00E
Copy link

e00E commented Apr 10, 2025 •
edited
Loading

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.
@e00E e00E added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Apr 10, 2025
@e00E e00E mentioned this issue Apr 10, 2025
Closed
@weihanglo
Copy link
Member

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?

@weihanglo weihanglo mentioned this issue Apr 10, 2025
Merged
github-merge-queue bot pushed a commit that referenced this issue Apr 10, 2025
@epage
fix(package): detect dirtiness for symlinks to submodule (#15416)
f2c4849 
### What does this PR try to resolve?

If a there is a symlink into a git repository/submodule,
when checking its git status with the wrong outer repo,
we'll get an NotFound error,
as the object doesn't belong to the outer repository.
This kind of error blocked the entire `cargo package` operation.

This fix additionally discovers the nearest Git repository,
and then checks status with that,
assuming the repo is the parent of the source file of the symlink.
This is a best effort solution, so if the check fails we ignore.

### How should we test and review this PR?

If we don't want the complication,
we could drop the last commit, ignore the error, and forget about
handling submodules

fixes #15384
fixes #15413
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

fix(package): detect dirtiness for symlinks to submodule weihanglo/cargo
2 participants
@e00E @weihanglo