dulwich - clone from remote repo authentication

Question

I couldn't find any resource on this topic. I need to clone from a private repository by providing the username and the password. However when they are provided as keyword arguments to 'dulwich.get-client-from-path()' an error occurs saying 'unknown argument "username"'.

This seems to be a simple thing to do, however I can't find the proper method.

Winkler

have you tried using pygit? – Unsociable

@user12321 does it use the git binary or does it manipulate the index to carry out the tasks? The main reason I chose Dulwich was its use of the index. – Winkler

any progress on this issue? – Treblinka

Nothing so far. I've opened an issue on Dulwich's github repo. – Winkler

Answer 1

Try this snippet:

porcelain.clone("https://user:password@your_git_repo.git")

Calchas

At the time this wasn't possible, but this has been fixed now in Dulwich. Accepting answer. – Winkler

Answer 2

This works as well:

porcelain.clone("https://example.com/repo.git", username="user", password="password")

I quickly checked to see if the credentials are stored locally:

• When using the username and password syntax from this answer, neither username nor password seem to be stored anywhere.
• When using the method from harvin's answer, the username is stored locally (you can check this on the command line with git remote -v). The password does not seem to be stored.
  • This is different from the behavior of executing git clone https://user:[email protected]/repo.git on the command line, which stores both username and password.

How I found out

1. The Dulwich porcelain documentation does not mention the possibility to clone with authentication at all.
2. The source code for porcelain.clone does take **kwargs.
   • They are passed to client.get_transport_and_path.
   • This passes them to client.get_transport_and_path_from_url.
   • This passes them to HttpGitClient.from_parsedurl. If username and password are present in the URL, they are extracted and stored into the kwargs dictionary (this probably is what makes harvin's answer work).
   • The kwargs dictionary is then passed on again somewhere. I did not check that location out, because the fact that the code knows about a username and a password key in kwargs was enough evidence for me to just try the snippet I posted above, and it worked.

Wadleigh