I didn't want to have to organize my work and personal repos using a directory structure, so I use matching on the remote instead. Since my job uses a GitHub organization, I'm able to conditionally include a config file that uses my work email in any GitHub repo under that organization.
I think this might be more interesting than the directory structure way. For years I've had the same setup of OP, but now that I think about it, this might make more sense for me.
Will give a look.
For years I've been using [direnv](https://direnv.net/) for this, setting environment variables which git picks up. This looks like a more feature complete equivalent, although to be honest I only really need switching of committer email and the SSH key used.
For the SSH part you can use ~/.ssh/config and it also has conditional stanzas like "Host foo.com" or "Host *.foo.com". Can set username, SSH Key, SSH Agent Socket (I use multiple SSH agents), etc.
Another trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is the "Match exec" directive which allows you to include a shell (bash) conditional (such as a directory-check), e.g.
Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/work/* ]]"
IdentityFile ~/.ssh/keys/work
User me-work
Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/personal/* ]]"
IdentityFile ~/.ssh/keys/personal
User me
Genuinely curios. After HTTPS became supported I never looked back. The whole authentication management and Git remote URL syntax are a huge mess I'd never want to touch unless forced to. HTTPS makes it a lot simpler... at least for me. Am I missing something?
I personally never managed to make pushes work over HTTPS, while with SSH it works the moment clone/pull works. Plus I vaguely remember that setting up HTTP auth was way more cumbersome that SSH auth.
Are you talking about server-side configuration or client-side?
I haven't had to set up Git server in a very long time. I'm not even sure if I had to set up HTTPS authentication for it. But, I can see how this may be potentially more difficult as you'd already have SSH set up for accessing the server by the time you get to set up Git.
It's been a lot easier on the client-side though. Especially having to deal with multiple users / multiple servers and having to share configuration between different machines. Usually it just boils down to having ~/.git-credentials and if necessary, adding a similar file in the root of the repo.
Client-side, of course. My password manager stores SSH keys and integrates with SSH seamlessly (it implements an ssh-agent), which took about 10 minutes to set up; I spent about an hour trying to integrate it with Git's own credential system to provide username-password pairs for HTTPS access and couldn't do it. So there.
Well, nowadays the popular managed Git services provide you with a simple way of setting up HTTPS access: you go to some page that generates an "auth token" or something along those lines, depending on the service you use, and they give you the line you should put in your ~/.git-credentials file.
But even if they don't, here's an example for Bitbucket (we use self-hosted Bitbucket at work):
The ~/.git-credentials file may contain multiple lines, and it doesn't have the same problem with escaping as, say, ~/.netrc (because stuff that goes into it needs to be URL-encoded). Also, unlike SSH, it can use password-based authentication (you cannot put your SSH password into ~/.ssh/config). So, this solves the part where you want to authenticate to different Git repos.
And if you want to use different personalities for authenticating to the same repo, you can change the location of the ~/.git-credentials file per repo. I was never in a situation where I had more than two roles in the same repo, so, usually, I'd alternate between the global .git-credentials and local-to-repo one. If it becomes really annoying, I'd have two checkouts of the same repo, but with credentials configured for different users.
PS. I would never use a password manger because of trust issues. I don't like random programs having weird integrations with it. Plus, it usually fails to understand the context in which password is to be supplied (eg. tries to show a pop-up window where pop-ups don't work). I store the information I want to be secret encrypted with GPG with a key with a passphrase. I use Emacs to keep a buffer with this file open, if I need passwords and copy from it when necessary. This is less automated and takes extra few seconds to do things that require authentication, but having once lost my password manager database to an upgrade... I'm once burned twice shy.
Or you can go to some another page, upload a public key, and then they also tell you that you should put such and such lines into your ~/.ssh/config file.
And no, I am not going to store passwords, or auth tokens, in an unencrypted plain text file thank you very much.
In my answer you replied to I suggested storing passwords in a GPG-encryped file. This also extends to .git-credentials (you can use GPG to encrypt it). I usually don't see a merit to that, but if the company policy is to keep such data encrypted, this is what I do.
I already described some of the downsides of ~/.ssh/config. Here are some others:
* You'd need to have the same private key on every computer you use. This is inconvenient, and raises the question of "how do I transfer my key?" And there aren't really good ways... Send with email? -- if your email is breached, then all your computers need to change keys quickly. Some kind of external storage? -- same thing when it's lost.
* I use SSH for a lot of things. I prefer that most things I needs SSH for on a particular computer use the default private key (so that I don't need to edit ~/.ssh/config every time I need to connect somewhere). In my line of work, on average, per day, I need to create couple dozens VMs which I then need to SSH to. Having to configure those to use a different key, even though these are throw-away VMs feels like too much of a chore.
There are downsides from the server admin perspective too. SSH, in general, will need a level of oversight inside an org to provision, expire, sign etc. the keys. Because SSH can, potentially, do a lot more things than HTTPS (when connecting to a server), admins need to be very careful giving SSH access only for the purpose of using Git. I.e. it's easy to give user actual Shell access (by accident) to the Git server instead of giving just Git access.
SSH can be very finicky when it comes to timeouts, encodings and a bunch of other options. But, still, my biggest problem with it is that it can do too much, and in the context of using Git it can bee too much by accident.
> I prefer that most things I needs SSH for on a particular computer use the default private key
Okay? You use non-default keys for hosts that host git repos, everything else gets the default key. I actually use exactly this configuration: my ~/.ssh/config has 4 entries, 3 of them for git servers I have push access to, and the fourth one is for a personal VPS. Everything else gets offered ~/.ssh/id_rsa
> There are downsides from the server admin perspective too.
That's the server admins' problem, not mine.
> SSH can be very finicky when it comes to timeouts, encodings and a bunch of other options
Can't really relate here, maybe you're right. But in my experience, it either just works fine, or doesn't work at all, no middle ground. Also, "encodings"?
All in all, my experience have been that Git over SSH Just Works™ while Git over HTTPS has all kinds of strange problems, inlcuding half-assedly written HTTP-proxies somewhere in the middle.
Well, if we expand arbitrary the range of programs reading ~/.ssh/config, then we can put there whatever we want, can't we? The point was that SSH won't read the password from its config file. There's a good reason not to do that: this configuration file shouldn't contain sensitive information because it's a plain text file. But, maybe you can encrypt it -- something I've never explored...
I avoid HTTPS for Git because I prefer not to have credential secrets sitting around unencrypted in my home directory. For SSH, I keep my private key on my Yubikeys.
I'd attempted to configure this some time back, but never gotten it working, and this was the kick in the pants I needed to finally get it working!
In case anyone is stuck in the same way that I was, the trailing slash at the end (which I had previously omitted, not realizing) is necessary for this to work. The docs[0] mention this, but I'd managed to repeatedly miss it:
> If the pattern ends with /, * will be automatically added. For example, the pattern foo/ becomes foo/*. In other words, it matches "foo" and everything inside, recursively.
You can also configure multiple ssh keys through Github subdomains in your ssh conf file. While github ignores the subdomain your ssh-client will pick the corresponding ssh key bas d on the used subdomain in your repo url.
This works only under the assumption Github won't change the current DNS setup that happens to work this way. A trivial example would be adding a record for the specific subdomain one used directing it to some completely different IP address. Not something I'd be willing to bet on, especially considering the much cleaner solution from the original post.
Do you mean a host alias in your SSH config (e.g. `Host your-github-alias` or configuring a subdomain in for the hostname in the config (e.g. `Hostname something-fake.github.com`)?
So subdomains can be arbitrary and you just manually add them when performing git clone? Will then git push/pull/etc automatically use the fake subdomain you like for this repository?
You are basically just repeating what he said, but it doesn't answer my question. After all I'm not ssh-ing to GitHub directly, I'd use git, which will use ssh as a transport, and I don't know if git will use the subdomains I provide the way I think it should (my primary concern being to prevent GitHub from displaying 2 public keys for a single account, so that 3rd party cannot tell that it's most probably the same person).
Of course, I can test it myself, but since somebody already does that I assumed I could just ask.
Yes this is what they mean. I've use this setup in the past when for example I wanted to use different SSH keys for bitbucket, gitlab and github for example.
man git-config, shows that so far there aren't many conditions available for testing. The location of the .git directory (as in the article). The name of the currently checked out branch. Or a pattern match against any remote URL in the configuration.
Oh nice, this will remove an annoyance in my dotfiles repo by letting me share my gitconfig between 3 different configurations (home linux amd64 box, work macOS arm64, client macOS arm64)
I just have a "config-private" file that I include in my main config, but I ignore it in the dotfiles repo. Git will ignore any included file if it does not exist. That lets me customize things locally without checking work details into version control.
The `username` is passed to the global secret helper and is thus used for it as part of the pick/prompt context for password. I'm using the libsecret helper but this works with any.
Useful when you want to have multiple git accounts changing based on the path. Thanks for the share! In my case it was changing the ssh key based on the project folder.
I prefer the method used in the article. All the settings are neatly kept in a git configuration file, and I don't have to track down where direnv keeps them, or remember that I need a separate tool in order to make it work. Also this allows you to set git config options that don't have a corresponding environment variable.
Something that wasn't addressed: when is the configuration read? Does this happen on every command-line git command execution? (I'm guessing "yes", but...)
Yes. Git doesn't daemonize, so there's no way it can avoid reading its configuration every time you run a command. Ultimately what the command ends up doing likely takes orders of magnitude longer than reading and parsing the config file, so it's not really a big deal.
You can probably still use the IDE for local operations that don't need custom configurations or server credentials, e.g. checkout, merge, commit, log, interactive visualizations of history, diff.
I do something similar, depending on the project and the identity I have to use.
For local Linux projects, I have Docker images for my development environments, one per identity. So I keep my PC as minimal as I can, while the compilers, interpreters, etc, are only installed within a Docker image.
Then I go to a project's directory, run a helper command like `identity1-workspace`, and it (1) starts the Docker container for `identity1`, (2) mounts the current directory to `/workspace` within the container, and (3) also mounts some cache directories, etc.
For other hosts where I don't want to use Docker (e.g. in Raspberry Pis, or in VPS) I just have multiple users and SSH into the one I want to use.
I can do this because I just use nvim and the terminal for everything, so for me there's basically no difference between developing "natively" vs developing inside a Docker container vs developing through SSH. The only difference is whether I run the command `nvim` vs `identity1-workspace` vs `ssh identity1`[1], respectively.
All this sounds like too much work, but I'd rather use (1) Docker, or (2) `adduser` and `ssh`, because those I can do from memory and can trust to be reliable since `identity1` can't push to repos of `identity2` even by accident. In comparison, the article's `includeIf` looks like something that could easily leak an identity by accident, not to mention that I'd forget its syntax after 2 days.
[1]: Well in this case also have to then `cd somewhere ; nvim` because writing a helper for this is no big deal.
> Why downvotes? It is the most effective way to separate config. If any of those "condition" fails, you may nuke or compromise your repo!
Maybe it was unusual enough that it didn't sound like a serious response (?), but you're completely right that the article's suggested solution can easily leak stuff by accident if you want to absolutely avoid committing with the wrong identity, thus revealing name, email, timezone, or some other metadata, in a repository where you don't want to.
If I contribute to a legal-gray-area anime fansub I don't want those people (other contributors) to know anything about my IRL identity, for example, so of course I'd reduce the possibility of info leaks due to typos or because my muscle memory betrayed me.
Like I mentioned in a sibling reply, I'd rather use a completely different OS user[1], a Docker container, or a different host.
I wrote it up here, if that sounds useful: https://www.brantonboehm.com/code/conditional-git-config/