'cargo install --git' assumes 'master' branch instead of using 'HEAD'

[Nemo157]

When trying to install rustc-l10n I got an error message from cargo

→ cargo install --git https://github.com/xen0n/rustc-l10n
    Updating git repository `https://github.com/xen0n/rustc-l10n`
error: failed to find branch `master`

Manually checking out the repo and looking at the refs I found that it has a HEAD ref pointing to the branch develop

→ git branch -av
* develop                922aea9 docs(README): update README
  remotes/origin/HEAD    -> origin/develop
  remotes/origin/develop 922aea9 docs(README): update README

It seems to me that cargo should probably be installing from the HEAD ref rather than assuming everyone sticks with the master branch convention.

EDIT: Just tried specifying it as a dependency and got the same error as well, I presume if there's anywhere else cargo takes a git repository it likely has the same behaviour.

[alexcrichton]

Ah seems reasonable to me! I suspect that there's some git-fu we could apply here to sort this out not in too difficult a fashion.

[Nemo157]

Just changing the default GitReference::Branch("master") to GitReference::Branch("HEAD") might actually work (although, assuming libgit2 is strict about what is a branch it probably won't).

If not, probably adding a new GitReference::Head or something would be the easiest solution, that should be simple to plumb through and then add an impl of GitDatabase::rev_for to return the revision for refs/remotes/origin/HEAD (maybe with a fallback to refs/remotes/origin/master as I feel like I've seen a git server not return HEAD at some point in the past).

If this is changed for dependencies as well then the docs probably also need updating, e.g. Specifying Dependencies mentions the master branch.

[alexcrichton]

Yeah we can perhaps test out updating just the install path first and then updating the dependencies path, I fear that updating the way we interpret dependencies may be a breaking change so we might have to hold off on that.

[atenjin]

It seems that this bug may occur in cargo update?
I do a test for a repo which not has the master branch:

-->$ git branch -av
  develop                b6a2467 in develop
* wtf                    cd38557 wtf master
  remotes/origin/develop b6a2467 in develop

and clear all caches in ~/.cargo/git/db and ~/.cargo/git/checkout

then I do cargo update/run/build in a test project

[dependencies]
cargo-deps-test = { git = "https://github.com/JKingdom/cargo-deps-test.git" }

It would show:

-->$ cargo run
    Updating git repository `https://github.com/JKingdom/cargo-deps-test.git`
error: failed to load source for a dependency on `cargo-deps-test`

Caused by:
  Unable to update https://github.com/JKingdom/cargo-deps-test.git

Caused by:
  failed to find branch `master`

Caused by:
  cannot locate local branch 'master'; class=Reference (4); code=NotFound (-3)

my cargo version is

-->$ cargo --version
cargo 1.33.0-nightly (2cf1f5dda 2018-12-11)

[ErichDonGubler]

I'm still getting bitten by the remote HEAD being assumed to be master in Rust 1.47.0 -- has this not been released yet?

$ cargo install --git https://github.com/aeshirey/waitfor
    Updating git repository `https://github.com/aeshirey/waitfor`
error: failed to find branch `master`

Caused by:
  cannot locate remote-tracking branch 'origin/master'; class=Reference (4); code=NotFound (-3)

Output of `rustup show`

$ rustup show

Default host: x86_64-pc-windows-msvc
rustup home:  C:\Users\erich\.rustup

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

stable-x86_64-pc-windows-msvc (default)
nightly-2020-02-27-x86_64-pc-windows-msvc
nightly-x86_64-pc-windows-msvc
1.45.0-x86_64-pc-windows-msvc
1.45.1-x86_64-pc-windows-msvc
1.45.2-x86_64-pc-windows-msvc
1.46.0-x86_64-pc-windows-msvc

installed targets for active toolchain
--------------------------------------

i686-pc-windows-msvc
x86_64-pc-windows-msvc

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

stable-x86_64-pc-windows-msvc (default)
rustc 1.47.0 (18bf6b4f0 2020-10-07)

[ehuss]

@ErichDonGubler It was reverted due to some problems. This issue probably should have been reopened. A new implementation was made in #8522, but it is requiring more work to complete.

It might be possible to directly support cargo install --git, assuming there aren't any non-default-master git dependencies, but it may require some special-casing.