Skip to content
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.

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

Allow gitignore of Cargo.lock with explicit include. #7448

Merged
merged 1 commit into from
Sep 27, 2019

Conversation

ehuss
Copy link
Contributor

@ehuss ehuss commented Sep 26, 2019

If a package has an include list, but Cargo.lock is in .gitignore, then Cargo would complain that Cargo.lock is "dirty". This changes it so that ignored Cargo.lock is allowed, even though it is still packaged. This is under the presumption that Cargo.lock is machine generated, so it is not critical. This was also an unexpected regression.

If you don't have an include list, then there is no complaint about Cargo.lock being dirty because Cargo uses git to deduce the file list, and Cargo.lock would be skipped for the dirty check (but still included in the package).

Closes #7319

@rust-highfive
Copy link

r? @nrc

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 26, 2019
@alexcrichton
Copy link
Member

@bors: r+

@bors
Copy link
Contributor

bors commented Sep 27, 2019

📌 Commit 36f01e6 has been approved by alexcrichton

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Sep 27, 2019
@bors
Copy link
Contributor

bors commented Sep 27, 2019

⌛ Testing commit 36f01e6 with merge d096a86...

bors added a commit that referenced this pull request Sep 27, 2019
Allow gitignore of Cargo.lock with explicit `include`.

If a package has an `include` list, but `Cargo.lock` is in `.gitignore`, then Cargo would complain that `Cargo.lock` is "dirty".  This changes it so that ignored `Cargo.lock` is allowed, even though it is still packaged.  This is under the presumption that `Cargo.lock` is machine generated, so it is not critical.  This was also an unexpected regression.

If you don't have an `include` list, then there is no complaint about `Cargo.lock` being dirty because Cargo uses git to deduce the file list, and `Cargo.lock` would be skipped for the dirty check (but still included in the package).

Closes #7319
@bors
Copy link
Contributor

bors commented Sep 27, 2019

☀️ Test successful - checks-azure
Approved by: alexcrichton
Pushing d096a86 to master...

@bors bors merged commit 36f01e6 into rust-lang:master Sep 27, 2019
@ehuss ehuss added this to the 1.40.0 milestone Feb 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

cargo publish and cargo package incorrectly complain about .gitignored Cargo.lock in library
5 participants