Problem

Given multiple dependencies fetched from the same git repo, e.g.:

[dependencies]
tracing = { git = "https://github.com/tokio-rs/tracing", branch = "v0.1.x", version = "0.1.40" }
tracing-subscriber = { git = "https://github.com/tokio-rs/tracing", branch = "v0.1.x", version = "0.3.18" }

and Cargo.lock referring to multiple different git refs, e.g.:

[[package]]
name = "tracing"
version = "0.1.40"
source = "git+https://github.com/tokio-rs/tracing?branch=v0.1.x#8b7a1dde69797b33ecfa20da71e72eb5e61f0b25"

[[package]]
name = "tracing-core"
version = "0.1.32"
source = "git+https://github.com/tokio-rs/tracing?branch=v0.1.x#6d00d7d9f72dc6797138a1062bc33073afbad5a1"

cargo tree (and even cargo build) will silently pick one of those git refs, ignoring the rest. All crates from the git repo will be built from the same revision, despite Cargo.lock specifying otherwise. No error or warning is emitted, and Cargo.lock isn't updated to reflect the actual revisions that end up being used.

The behaviour I expect is an error if --locked is passed to cargo.

In the absence of --locked, I'm not sure if I want to see an error or if Cargo.lock should be updated. Certainly it shouldn't just silently pick one though.

Alternatively, cargo could actually support having several different revisions for a single git repo. After all, if the crates in question were published into the registry, there'd be no problem of them having different versions.

Steps

1. cargo init, cargo build, git add ., git commit
2. cargo add --git https://github.com/tokio-rs/tracing --branch v0.1.x tracing tracing-subscriber, git commit
3. cargo update --precise 8b7a1dde69797b33ecfa20da71e72eb5e61f0b25 tracing, git commit
4. git checkout -p @^ (select only the tracing-core hunk)
5. cargo tree — all tracing* crates are at 6d00d7d9, but Cargo.lock still specifies 8b7a1dde… for most of them

(the above steps executed today are captured in the following git repo for future reference: https://github.com/liskin/2024-07-10-cargo-lock-git-bug)

Possible Solution(s)

No response

Notes

It could be argued that cargo update will never produce such inconsistencies in Cargo.lock.
Indeed, it was a "race condition" between two git pull requests: one person adding another dep from the repo, another bumping the revision of the existing deps. After merging the two independent PRs, we ended up with inconsistent revisions in Cargo.lock and were baffled why we can't use code that should now be available after the revision bump.

This was not an isolated incident. I went to check the rest of our codebase and found another instance of multiple different revs for a single git repo in Cargo.lock. So I'd argue this is not super rare, and should be handled by cargo somehow.

Version

cargo 1.79.0 (ffa9cf99a 2024-06-03)
release: 1.79.0
commit-hash: ffa9cf99a594e59032757403d4c780b46dc2c43a
commit-date: 2024-06-03
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Debian n/a (trixie) [64-bit]