Cargo "couldn't find remote ref refs/heads/master"

I have a GitHub dependency which uses main as the default branch. When attempting to use this dependency by specifying a commit hash, cargo will fail to fetch.

native-utils = { git = "ssh://git@github.com/edgeandnode/native-utils.git", commit = "6250251" }

Results in:

error: failed to get `native-utils` as a dependency of package `[redacted]`

Caused by:
  failed to load source for dependency `native-utils`

Caused by:
  Unable to update ssh://git@github.com/edgeandnode/native-utils.git

Caused by:
  failed to fetch into: /Users/zacharyburns/.cargo/git/db/native-utils-5e28c0ee099ac904

Caused by:
  process didn't exit successfully: `git fetch --force --update-head-ok 'ssh://git@github.com/edgeandnode/native-utils.git' 'refs/heads/master:refs/remotes/origin/master' 'HEAD:refs/remotes/origin/HEAD'` (exit code: 128)
  --- stderr
  fatal: couldn't find remote ref refs/heads/master

If I specify a branch this works temporarily, but creates problems of it's own as branches are impermanent. Other times that I have specified dependencies in GitHub cargo was able to find commits even if they were not a part of the master branch.

How can I get cargo to recognize that the default branch is main and find the commits?

I believe you can specify the branch name in the same way you specify the commit.

Note that you can specify both branch and commit:

native-utils = { git = "ssh://git@github.com/edgeandnode/native-utils.git", commit = "6250251", branch = "main" }

There is a plan to make Cargo automatically use the default branch instead of always looking for master, though this change is happening in phases to avoid breaking any existing projects. Some of the preparations for the change were merged into Cargo recently: Upcoming changes to `Cargo.lock` - cargo - Rust Internals

Edit: It looks like this is already fixed in the nightly toolchain.

I get that you can specify both. That consistently breaks in my workflow. The problem happens when:

  1. You have 2 crates under different GitHub repos. A & B where B depends on A.
  2. A new API is introduced for A in a branch, and a motivating use-case for the API is developed in B.
  3. The PRs go out simultaneously so that A can be reviewed as motivated by B.
  4. Change in A looks good, so it's merged and the branch is deleted.
  5. B is now broken! It refers to a deleted branch. If only specifying the commit hash is necessary, it is not broken because the commit is still there.

With this workflow there is no correct value to specify the branch.

Glad to hear this seems to already be in a pipeline to be fixed.

1 Like

Oops.

Turns out the right manifest key is rev, not commit.
Cargo will (rightly) error when both rev and commit are specified.

Specifying rev fixed my issue.

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.