Patching dependencies does not work if it's for the same location but a different branch

[sdroege]

E.g.

[patch.'https://github.com/sdroege/gobject-subclass']
gobject-subclass = { git = 'https://github.com/sdroege/gobject-subclass', branch = 'refactoring' }

This gives

error: failed to resolve patches for `https://github.com/sdroege/gobject-subclass`

Caused by:
  patch for `gobject-subclass` in `https://github.com/sdroege/gobject-subclass` points to the same source, but patches must point to different sources

[alexcrichton]

Ah yeah this is sort of an unfortunate side-effect of the implementation of patch in that it only looks at URLs, not at the full source. That is, you can't even say you only want to replace the source where the branch is master, instead a [patch] applies to all git sources with the same url (regardless of rev/branch/etc). That means that this is currently replacing itself as well, which is disallowed.

[jplatte]

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

[est31]

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

Nice workaround hack! Further ways to change the URL string include adding / to the url like https://github.com////user///repo . This method scales to unlimited amounts of different urls for the same repo.

[brenzi]

The above workaround doesn't work for us, because what we patch has dependencies as well which need to be patched by the workspace patch. However, as the url now changed, it won't be patched.
I thought I could just add another level of patching:

[patch.'https://github.com/scs/substrate']
primitives = { git = "https://github.com/scs//substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

[patch.'https://github.com/scs//substrate']
primitives = { git = "https://github.com/scs///substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

but that won't work:

cargo update
    Updating git repository `https://github.com/scs/ed25519-dalek.git`
    Updating git repository `https://github.com/scs///substrate`
warning: spurious network error (2 tries remaining): unexpected HTTP status code: 404; class=Net (12)
warning: spurious network error (1 tries remaining): unexpected HTTP status code: 404; class=Net (12)
error: failed to resolve patches for `https://github.com/scs//substrate`

Caused by:
  failed to load source for a dependency on `substrate-primitives`

Caused by:
  Unable to update https://github.com/scs///substrate?tag=substraTEE-M5.1

Caused by:
  failed to fetch into /home/abrenzikofer/.cargo/git/db/substrate-df78ab1b7ea0c505

Caused by:
  unexpected HTTP status code: 404; class=Net (12)

also linking it back to the original url won't work:

[patch.'https://github.com/scs/substrate']
primitives = { git = "https://github.com/scs//substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

[patch.'https://github.com/scs//substrate']
primitives = { git = "https://github.com/scs/substrate", package = 'substrate-primitives', tag = "substraTEE-M5.1" }

because:

thread 'main' panicked at 'assertion failed: prev.is_none()', src/tools/cargo/src/cargo/core/resolver/context.rs:153:25
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

[brenzi]

this bug has been open for a long time. is there hope? we're stuck with a suboptimal setup due to this.

[sjackman]

Any progress on this issue?

[brenzi]

this could IMO be fixed by #7497

[Diggsey]

I've definitely been confused by this because I didn't understand how the [patch] syntax for git repos could work without specifying a branch... Now that I've seen this bug it makes sense.

[sblackshear]

For GitHub repositories, one can work around this by [patch]ing https://github.com/user/repo to https://github.com/user/repo.git (or the other way around).

Nice workaround hack! Further ways to change the URL string include adding / to the url like https://github.com////user///repo . This method scales to unlimited amounts of different urls for the same repo.

These workarounds no longer do it for me (using cargo 1.52.0)--perhaps Cargo is now normalizing repo names?

[haythemsellami]

Have you tried this:

ethers-rs = { git = "https://github.com/gakonst////ethers-rs.git", branch = "test" }

The canonicalization code only strips trailing / and .git. For extra / inside the URL, it doesn't do anything.

I think this workaround fails with Cargo v, I did find another one:

ethers-rs = { git = "https://github.com:443/gakonst/ethers-rs.git?rev=test", branch = "test" }

[jplatte]

I think that's sufficiently different to have its own GitHub issue.

[Skgland]

Ah, I think my problem is already covered by #9227

[boyswan]

This worked for me (www and .git) :

[patch.'https://github.com/foo/bar']
baz = { git = "https://www.github.com/foo/bar.git", branch = "test" }

[metasim]

Conversation on prerequisites to addressing this issue: https://internals.rust-lang.org/t/how-to-assist-with-bug-5478/21819/1

[JakkuSakura]

Using ssh://[email protected]/owner/repo also works, in case previous hacks doesn't work

[simnalamburt]

If you want to patch a crate from crates.io with crates.io itself (which often comes up when you just want to change the version), you can do it like this:

# Cargo.toml
[patch.crates-io]
zip = { version = "=2.5.0", registry = "crates-io-2" }

# .cargo/config.toml
[registries]
crates-io-2 = { index = "sparse+https://index.crates.io/" }

This can lead to the same sub-dependency being downloaded from both crates-io and crates-io-2. It’s not a major issue to download the same dependency twice, but just be aware of it.

[metasim]

TIL: sparse+https