-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Cargo.lock updates automatically on cargo build
in 1.47.0-nightly
#8586
Comments
Can you share a little more detail on a reproduction? If you are referring to a change like you mentioned at tikv/tikv@b3f9c3325, then that is expected that when you change the URL, cargo will update the Cargo.lock for that dependency. If you need a specific git rev, you'll need to specify the |
Please note the updates to Cargo.lock that weren't made explicitly. https://github.com/de-sh/tikv/commit/d4af57a5c43aa94f88551d137ee55f53aee24ef4#r41190758 The changes are clear from building on 1.46.0-nightly, which doesn't update to the HEAD of git dependencies unless explicitly told to, unlike which 1.47.0-nightly does inexplicably update to latest HEAD on merely |
Ah, I see, sorry I misunderstood. I think this is a duplicate of #8468. This should be fixed on the latest nightly. I would use at least 2020-08-02. |
Can you guide me as to how I can do this?
|
I have emulated the same on travis: Maybe this is not fixed for 1.47.0-nightly unlike 1.46.0-nightly as mentioned in #8468 Reopening issue |
cargo build
cargo build
in 1.47.0-nightly
When a component is missing, there are several options for installing without that component:
The rustup documentation is at https://github.com/rust-lang/rustup, and via |
Problem
I am currently using
rustc 1.47.0-nightly (6c8927b0c 2020-07-26)
to build a crate containing multiple git based dependencies. The Cargo.lock to these dependencies automatically updates as a result of change to HEAD without explicit use ofcargo update -p
. I expected it to not update the dependencies and use the revisions from Cargo.lock as 1.46.0 used to do.Steps
Possible Solution(s)
Notes
Output of
cargo version
: cargo 1.47.0-nightly (aa68721 2020-07-23)This asciinema makes note of how the error comes to be while building the project. Checkout side-effects mentioned as latest commit to this branch:
The text was updated successfully, but these errors were encountered: