If rev is added to git url cargo gives no warnings and has unexpected behavior

[mjarkk]

Problem
I have 2 git repos in my Cargo.toml:

[dependencies]
juniper-actix = { git = "https://github.com/graphql-rust/juniper#91a33539", package = "juniper_actix" }
juniper = { git = "https://github.com/graphql-rust/juniper#91a33539" }

When cargo downloads / compiles these packages it shows the #91a33539 2 times:

> cargo build
    Updating git repository `https://github.com/graphql-rust/juniper#91a33539`
   Compiling juniper_codegen v0.14.2 (https://github.com/graphql-rust/juniper#91a33539#91a33539)
   Compiling juniper v0.14.2 (https://github.com/graphql-rust/juniper#91a33539#91a33539)
   Compiling juniper_actix v0.1.0 (https://github.com/graphql-rust/juniper#91a33539#91a33539)

Steps

1. Run cargo init
2. Add the deps shown above to the dependencies
3. Run cargo build

Possible Solution(s)
Show an error with a note to add rev = ".." to the dep or support adding a rev to the URL

Notes

Output of rustup show:

> rustup show
Default host: x86_64-unknown-linux-gnu
rustup home:  /home/mark/.rustup

installed toolchains
--------------------

stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)

active toolchain
----------------

nightly-x86_64-unknown-linux-gnu (directory override for '/home/mark')
rustc 1.45.0-nightly (7ced01a73 2020-04-30)

[ehuss]

I think the #foo in the URL is ignored in this case. To specify the revision, use the rev = "91a33539" field. And, unfortunately, it appears that is completely undocumented!

[mjarkk]

Thanks didn't know this but still wired this isn't specified in the documentation.

[Eh2406]

Is the # syntax required to mean that for all git urls or is it just a github thing?
If it is a git thing, then maybe we should support it.
If it is a github thing, then maybe we should have a warning for urls with both github.com and # recommending the correct syntax.

[ehuss]

I can see how that's confusing. It's actually not a github thing, it's a Cargo thing. When Cargo displays a "git source", it displays it in a short format with a hash anchor. GitHub will ignore that completely. GitHub ignores that as a normal URL, but it breaks access with the git protocol.

I'm actually not sure how Cargo should deal with that. Some options off the top of my head:

• Do nothing, leave it broken. 😜
• Detect the # fragment, and return a warning or error.
• Remove the # fragment, otherwise ignore it.
• Detect the # fragment, and interpret as a git revision (and remove it from the URL).

[mjarkk]

Detect the # fragment, and return a warning or error.

I think this is the best option because i guess setting the ref also change other things beside the hash in the URL and because setting the ref is what you are supposed to do.

Remove the # fragment, otherwise ignore it.

Doesn't help the user fixing what they are trying to-do. For example i wanted to add a ref and saw that the cargo output shows the ref in the url so i try to do the same thing, not really helpful if it just gets ignored because now i have to google for a solution.

Detect the # fragment, and interpret as a git revision (and remove it from the URL).

Works but because i guess it also changes other things beside the url hash it will lead new users to believe that this is how git works.

[joshtriplett]

We discussed this in today's Cargo meeting, and came to the conclusion that we should notice URLs with fragments in them, warn, and in the warning tell people "if you were trying to specify a specific git revision, use rev = "revision"."

We'd welcome an implementation of that logic.

[mjarkk]

can i give making this a try i'm still very new to rust and this would be a nice way to learn a bit more about rust?

[Eh2406]

@mjarkk Yes, go for it. Feel free to ask here or on discord if we can help!

[mjarkk]

I've created a mr to try to fix this #8297