fails to update crates.toml after updating installed git package

[matthiaskrgr]

The package is out of date according to cargo install-update

Package              Installed                                 Latest                                    Needs update
rustup               d9690a846c82d23f53af0f6cec82015d1a387577  22b6cdb8b000f9217af1dd5dd4e73ce032bdb25d  Yes

crates.toml:

"rustup 1.13.0 (git+https://github.com/rust-lang-nursery/rustup.rs#d9690a846c82d23f53af0f6cec82015d1a387577)" = ["rustup-init"]

I manually updated it
cargo install --git https://github.com/rust-lang-nursery/rustup.rs

    Updating git repository `https://github.com/rust-lang-nursery/rustup.rs`
  Installing rustup v1.13.0 (https://github.com/rust-lang-nursery/rustup.rs#22b6cdb8)
   Compiling libc v0.2.42
   Compiling cfg-if v0.1.4
[...]
   Compiling download v0.4.0 (https://github.com/rust-lang-nursery/rustup.rs#22b6cdb8)
   Compiling rustup-utils v1.13.0 (https://github.com/rust-lang-nursery/rustup.rs#22b6cdb8)
    Finished release [optimized] target(s) in 5m 57s
  Installing /home/matthias/.cargo/bin/rustup-init

however the new git hash is not updated in crates.toml:

"rustup 1.13.0 (git+https://github.com/rust-lang-nursery/rustup.rs#d9690a846c82d23f53af0f6cec82015d1a387577)" = ["rustup-init"]

Wasn't that just fixed a month ago or so?

cargo 1.29.0-nightly (506eea76e 2018-07-17)
release: 1.29.0
commit-hash: 506eea76edbf7198258265ddabcf320365bc4c5c
commit-date: 2018-07-17

rustc 1.29.0-nightly (6a1c0637c 2018-07-23)
binary: rustc
commit-hash: 6a1c0637ce44aeea6c60527f4c0e7fb33f2bcd0d
commit-date: 2018-07-23
host: x86_64-unknown-linux-gnu
release: 1.29.0-nightly
LLVM version: 7.0

[matthiaskrgr]

Previous ticket: #4582
Previous fix PR: #5564

[matthiaskrgr]

Ok this seems to be tied to rustup git in some strange way, I was able to update alacritty git and the crates.toml was updated properly.
I also noticed that cargo did not ask for --force when "reinstalling" the crate which seems suspicious to me, reinstalling with --force did not make a difference though.

[matthiaskrgr]

I tried to play around a bit more, is there a way to install a git crate via --git without pushing it to the internet?

cargo install --git /tmp/aa does not seem to work error: invalid url `/tmp/aa`: relative URL without a base which is strange since git itself has not problem with cloning repos via local paths, like git clone /tmp/foo /tmp/bar

[ehuss]

is there a way to install a git crate via --git without pushing it to the internet?

You can use a path URI: cargo install --git file:///path/to/repo

[mati865]

I think it's related to the broken Ord trait: #4582 (comment)

In #5564 I've added workaround for upgrade procedure (when binary is installed and we install newer version on top of it).
It doesn't work here because cargo thinks you are installing new binary (no idea why).

Similar workaround could be added before line where Ord trait is used but I think it would be better to fix cargo to detect it as an upgrade instead of a new installation. Reduced test case would be helpful.

[matthiaskrgr]

This just happened to me again, with the rustup git repo.

I wonder if there is something strange with that repo in particular that confuses cargo 😕

edit: corrupted metadata (binary missing)
error: corrupt metadata, `/home/matthias/.cargo/bin/rustup-init` does not exist when it should

[matthiaskrgr]

Ok, cargo corrupts its cache when binaries change names :(

[ehuss]

I believe this issue doesn't exist anymore. If you can make a reproduction on latest Cargo, feel free to reopen with instructions. Since this issue was written, hashing/comparison of PackageId's have changed (they now use exact source_id comparison), and install-tracking has been completely rewritten (which has explicit handling for git hash changes).