How to store credentials locally per repo in Git Credential Manager for Windows?

Question

I have 2 github accounts (work & personal) for which I want to store credentials in my Windows 10 (in secure way).

git config --global credential.helper manager command sets only single username & password which conflicts between personal repo and work repo in my machine. Both repo are cloned using HTTPS.

I want to store and access different credentials probably based on repo username. Is it possible?

I know SSH is an option but I would like to know the way for HTTPS.

Answer 1

Username in URL

On Bitbucket, you can add a username to the HTTPS url of your remote:

• use: https://[email protected]/path/repo.git
• instead of: https://bitbucket.org/path/repo.git

Since the url is technically different, you can add both your work and personal forks as remotes for the same repository if you want to. Issue #749 for the legacy Git Credential Manager suggests that the username-in-url technique works on GitHub as well, but other repo hosts may not support it.

Set useHttpPath

More generally, you can use credential.useHttpPath to split credential management for multiple repositories run by the same host. The quote below from the legacy Git Credential Manager documentation includes CLI for setting it on bitbucket.com, but you can modify for your own purposes or take a look at the longer example text in the newer GCM Core docs.

useHttpPath

Instructs Git to supply the path portion of the remote URL to credential helpers. When path is supplied, the GCM will use the host-name + path as the key when reading and/or writing credentials.

Note: This option changes the behavior of Git.

Supports true or false. Defaults to false.

git config --global credential.bitbucket.com.useHttpPath true

As rjmunro notes in the comments, you can drop --global to use the path for only the current repo. If so, you may as well drop the hostname, too:

git config credential.useHttpPath true

This second method does not help if you want to log into the exact same repo with different credentials on a whim. (See GCM #363.)

Answer 2

You could do it with a different helper e.g. git-credential-store which takes an optional parameter for a credential file path. You could set this in local config in each repo, with a different credentials file for each repository.

Alternatively use the suggestion in the link in @phd's comment which should work for Git Credential Manager For Windows

Answer 3

More generally, you can use credential.useHttpPath to split credential management for multiple repositories run by the same host. ^[‡]

In that case, use Git 2.27 (Q2 2020), because the parsing of URL for the credential helper has been corrected.

See commit 4c5971e (14 Apr 2020) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit a397e9c, 22 Apr 2020)}

credential: treat "?" and "#" in URLs as end of host

^{Signed-off-by: Jeff King}

It's unusual to see:

https://example.com?query-parameters

without an intervening slash, like:

https://example.com/some-path?query-parameters

or even:

https://example.com/?query-parameters

but it is a valid end to the hostname (actually "authority component") according to RFC 3986. Likewise for "#".

And curl will parse the URL according to the standard, meaning it will contact example.com, but our credential code would ask about a bogus hostname with a "?" in it.

Let's make sure we follow the standard, and more importantly ask about the same hosts that curl will be talking to.

It would be nice if we could just ask curl to parse the URL for us.
But it didn't grow a URL-parsing API until 7.62, so we'd be stuck with fallback code either way.
Plus we'd need this code in the main Git binary, where we've tried to avoid having a link dependency on libcurl.

But let's at least fix our parser. Moving to curl's parser would prevent other potential discrepancies, but this gives us immediate relief for the known problem, and would help our fallback code if we eventually use curl.

---

With Git 2.35 (Q1 2022), credentials and other variable value benefit from the latest of RFC 3986: treat "_" as any other URL-valid characters in an URL when matching the per-URL configuration variable names.

See commit e4c497a (12 Oct 2021) by Jeff King (peff).
^{(Merged by Junio C Hamano -- gitster -- in commit 96eca02, 29 Nov 2021)}

urlmatch: add underscore to URL_HOST_CHARS

^{Reported-by: Alex Waite}
Signed-off-by: Jeff King

When parsing a URL to normalize it, we allow hostnames to contain only dot (".") or dash ("-"), plus brackets and colons for IPv6 literals.
This matches the old URL standard in RFC 1738, which says:

host           = hostname | hostnumber
hostname       = *[ domainlabel "." ] toplabel
domainlabel    = alphadigit | alphadigit *[ alphadigit | "-" ] alphadigit

But this was later updated by RFC 3986, which is more liberal:

host        = IP-literal / IPv4address / reg-name
reg-name    = *( unreserved / pct-encoded / sub-delims )
unreserved  = ALPHA / DIGIT / "-" / "." / "_" / "~"

While names with underscore in them are not common and possibly violate some DNS rules, they do work in practice, and we will happily contact them over http://, git://, or ssh://.
It seems odd to ignore them for purposes of URL matching, especially when the URL RFC seems to allow them.

There shouldn't be any downside here.
It's not a syntactically significant character in a URL, so we won't be confused about parsing; we'd have simply rejected such a URL previously (the test here checks the url code directly, but the obvious user-visible effect would be failing to match credential.http://foo_bar.example.com.helper, or similar config in http.<url>.*).

Arguably we'd want to allow tilde ("~") here, too.
There's likewise probably no downside, but I didn't add it simply because it seems like an even less likely character to appear in a hostname.