Cargo version resolution with rev.0

I have a crate and the other crate as a dependency.
It is specified like this:

tag = "0.0.0+rev.0"
default-features = false
git = "ssh://"

every time I run cargo update I get
Removing pkg_rs v0.0.0 (ssh:// rev.0#e9e7eb16)
Adding pkg_rs v0.0.0 (ssh://

Why cargo does that?

Well, to update your dependency. You may know your tag won't change to a different commit. But Cargo doesn't, so it needs to check that when you update the dependency. The closest piece of documentation I could find on how updating git dependencies work is this:

Once a git dependency has been added, Cargo will lock that dependency to the latest commit at the time. New commits will not be pulled down automatically once the lock is in place. However, they can be pulled down manually with cargo update.


Well, Cargo could literally just check if the commit hash has changed rather than always removing+adding. But I presume optimizing git dependency management isn't at the top of the priority list in the Cargo project as git deps are considered a fairly niche thing.


I'm not familiar with the actual code, but I presume the only real benefit would be that the log messages would disappear. I don't imagine there to be any other benefits like improved performance. Cargo would still need to pull the latest commits in order to check whether a tag has changed to a different commit.

Me neither, but git fetch by default negotiates with the remote to avoid re-fetching unchanged things, and I presume it’s the same with whatever API Cargo uses. So yeah, actually I guess there’s not much there to optimize assuming the redundant remove/add cycle is entirely local.

1 Like

This looks like the bug not yet released. Still waiting for consensus on a new lockfile version.


Oh! nice to see it is resolved already, bad it's still not stabilized but I hope it will land at some point

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.