What do you mean by "versioning support for git dependencies"? We do support pulling in git dependencies based on a branch (I think tags work?)
We also support checking the version of the git dep.
It's fetching the dep that's the problem. Git has no uniform protocol for talking about versions, especially when it comes to resolving SemVer ("you asked for 0.2.1 but I also have 0.2.5, here you go")
If you want go-style import resolution use a local git dep. That works fine. It's specifically when you want all the features of cargo's version resolution -- which git doesn't understand -- you need to use a custom registry.
"Versioning support" is the wording from the release notes. I don't know why cargo's version resolution logic can't be applied to git dependencies, treating a tag like "v4.2" or "4.2" as a version 4.2 doesn't seem very contentious. I also don't know what you mean by local git dep.
> I also don't know what you mean by local git dep.
Presumably, the `git` URL for dependencies, in `Cargo.toml`, can point to a local git repository.
That should let you refer to a branch / commit of that repository, other than the one currently checked out (which is what using a `path` dependency would give you).
We also support checking the version of the git dep.
It's fetching the dep that's the problem. Git has no uniform protocol for talking about versions, especially when it comes to resolving SemVer ("you asked for 0.2.1 but I also have 0.2.5, here you go")
If you want go-style import resolution use a local git dep. That works fine. It's specifically when you want all the features of cargo's version resolution -- which git doesn't understand -- you need to use a custom registry.