git_crendetials not used in GitRepoProvider

[billux]

Bug description

When using GitRepoProvider, the git_credentials are not used to fetch remote git ref before spawning repo2docker.

How to reproduce

0. BinderHub is installed as described in the official guide.
1. I added the following override to values.yaml to set git a valid username/token, according to these instructions for the credentials format:

config:
  GitRepoProvider:
    git_credentials: "username=[redacted]\npassword=[redacted]"

2. Then, I tried to start a Binder on a private git repository, selecting Git repository in the dropdown list
3. The build fails immediately with the following error:

Error resolving ref for git:https%3A%2F%2F[redacted]/HEAD: Unable to run git ls-remote to get the `resolved_ref`: fatal: could not read Username for 'https://[redacted]': No such device or address

When I try to clone a public git repository (to go behond that error), I do see my credentials passed to the builder pod, so I guess my config is correct:

$ kubectl describe pod build-https-3a-2f-2fxxxxxxxx-607a08-f00-84
[…]
Containers:
  builder:
    Environment:
      GIT_CREDENTIAL_ENV:  username=[redacted]
                           password=[redacted]

I'm pretty sure the bug lies in the GitRepoProvider class, where get_resolved_ref() here doesn't use the git_credentials at all, whereas other classes such as GitLabRepoProvider do use it (like here) to build the git URL.

Someone also reported the same problem years ago on this Discourse thread.

[welcome]

Thank you for opening your first issue in this project! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out Jupyter's Code of Conduct. Also, please try to follow the issue template as it helps other other community members to contribute more effectively.

You can meet the other Jovyans by joining our Discourse forum. There is also an intro thread there where you can stop by and say Hi! 👋

Welcome to the Jupyter community! 🎉

[yuriburger]

Ran into this issue last week too. Indeed the issue is as @billux described: the git ls-remote tries to resolve the git reference and doesn't use the credentials at this stage (it does use them after spawning the repo2docker container so the git clone of a private repo works).

Investigating a fix, but as a workaround, you can provide the full (40 character) SHA and bypass the git ls-remote.