Revert "fix(package): detect dirtiness for symlinks to submodule" #15419
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This reverts commit 71ea2e5. `Repository::discover` and `Repository::status_file` are too expenstive to run inside a loop. And `cargo package` are doing a lot of duplicate works for checking submodule VCS status. The possible fix might look like * Let `status_submodules` function returns a path entry set, so Cargo can check whether a source file is dirty based on that. * When listing files in `PathSource`, attach the VCS status of a path entry assoicated with. Then subsequent operations can skip status check entirely. The above solutions are not trivial, and the dirtiness check is informational only based on T-cargo conclusion, so we should be good just reverting the change now. Again, the caveat of this is that we can't really detect dirty symlinks that links into a Git submodule.
rustbot
added
A-git
epage
approved these changes
Apr 11, 2025
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 12, 2025
Update cargo 12 commits in 0e93c5bf6a1d5ee7bc2af63d1afb16cd28793601..864f74d4eadcaea3eeda37a2e7f4d34de233d51e 2025-04-05 00:00:24 +0000 to 2025-04-11 20:37:27 +0000 - chore: Bump build-rs version (rust-lang/cargo#15421) - fix(build): Correct name of CARGO_CFG_FEATURE (rust-lang/cargo#15420) - Revert "fix(package): detect dirtiness for symlinks to submodule" (rust-lang/cargo#15419) - Improved error message when build-dir template var is invalid (rust-lang/cargo#15418) - Added validation for unmatched brackets in build-dir template (rust-lang/cargo#15414) - fix(package): detect dirtiness for symlinks to submodule (rust-lang/cargo#15416) - chore(deps): bump crossbeam-channel from 0.5.14 to 0.5.15 (rust-lang/cargo#15415) - docs(metadata): Added build_directory to cargo metadata documentation (rust-lang/cargo#15410) - Added symlink resolution for `workspace-path-hash` (rust-lang/cargo#15400) - feat: print target and package names formatted as file hyperlinks (rust-lang/cargo#15405) - docs(ref): Use better example value in `CARGO_CFG_TARGET_ABI` (rust-lang/cargo#15404) - chore: Bump cargo-util-schemas to 0.8.2 (rust-lang/cargo#15403) r? ghost
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this PR try to resolve?
This reverts commit 71ea2e5.
Repository::discoverandRepository::status_fileare too expenstiveto run inside a loop. And
cargo packageare doing a lot of duplicateworks for checking submodule VCS status.
Alternative fixes might look like
status_submodulesfunction returns a path entry set, soCargo can check whether a source file is dirty based on that.
PathSource, attach the VCS status of apath entry assoicated with. Then subsequent operations can skip
status check entirely.
However, the above solutions are not trivial, and the dirtiness check is
informational only based on T-cargo conclusion, so we should be
good just reverting the change now.
Again, the caveat of this is that we can't really detect
dirty symlinks that link into a Git submodule.
How should we test and review this PR?
Should be good to merge. We still got #15384 fixed via d760263
Additional information
See #15384 (comment).