Conditional Git Configuration | Hacker News Reader

Conditional Git Configuration

blog.scottlowe.org

286 pointsdjha-skin70 comments

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 wrote it up here, if that sounds useful: https://www.brantonboehm.com/code/conditional-git-config/

This is just what I need.

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.

Nice.

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.

You don’t need for config for the SSH piece as it defers to SSH’s own config for it.

If you’re using SSH for commit signing, you do need that in your git configuration.

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.

meh.

it's much easier to have a conditional git config in ~/.gitconfig that modifies the git ssh command to explicitly use a different ssh key.

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

Nice trick! I'd usually set alias in ~/.ssh/config and set origin to match that alias, e.g.

    Host project-foo
    Hostname github.com
      User git
      IdentityFile ~/.ssh/some_key

Then I'll pull the project with:

    git clone project-foo:/Foo/project.git

What's the reason to want SSH over HTTPS for Git?

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):

    https://$USER:$PASSWORD@bitbucket.$COMPANY.com%3a$PORT

and then in ~/.gitconfig

    [credential]
 helper = store

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.

> (you cannot put your SSH password into ~/.ssh/config)

you can, however, use `ssh-agent` (and should!)

Why do you believe anyone should use ssh-agent?

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...

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 an unencrypted

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.

> You'd need to have the same private key on every computer you use.

No you don't. You use different private keys on different computers, they are really not that expensive to mint. This also simplifies revocation.

> "how do I transfer my key?"

If you really, really need that, it's very simple: curl https://github.com/Joker-vD/keepassdb/raw/master/Joker_vD.kd...

> 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.

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.

[0]: https://git-scm.com/docs/git-config#Documentation/git-config...

Surprised no one has mentioned chezmoi[1], which takes parameterization of configs to its awesome, extreme conclusion[2].

[1]: https://chezmoi.io/

[2]: https://github.com/cglong/dotfiles/blob/ea33143679e936f4043a...

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.

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 can have anything you’d like in your ssh config and it will be treated as a server name for auth and auto completion.

So “work-github” can be a Host entry (with a HostName of github.com) and key A. While “play-github” would use key B.

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.

I tested it myself, like `ssh git@rando.github.com` and that didn't work.

That was my interpretation of the original comment. (reading it again, it seems like it was indeed saying what I typed below)

It seems like the reply was saying instead you can do in your .ssh/config file

   Host work.github.com
   HostName github.com
   Host me.github.com
   HostName github.com

(or just leave out the .github.com in the Host part)

So `ssh git@me.github.com` now works...

And then key the github config off of that? But I didn't try that part. So I could be wrong there.

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.

It works even for same hostname like I did here - https://github.com/hashhar/dotfiles-tmp/blob/master/ssh/.ssh...

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`)?

I did not know about `includeIf`...this allows getting rid of the hacks I used to achieve something similar, great!

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)

Thank you for sharing it!

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.

That's a neat way of doing it, I will do the same, thank you!

What do you have in your git config that requires switching over host architecture?

I put those there as a way to show I couldn't just switch on $ARCH or $OSTYPE similar. I should have explained that better, sorry about that.

Ah, gotcha. I thought you might have some weird, nice needs and was curious about it :)

I use it to set my personal and my work email to different projects

Can different .git-credentials files also be loaded conditionally? When one uses https access with multiple accounts....

You could probably write a custom git credential helper that does that, if it doesn't exist already.

Do you need multiple files? Since you can store credentials for multipl users and host combinations in the same file.

I use the technique in article for something similar that solves the same problem. I'll find it on pc in a sec.

~/.gitconfig:

    [credential]
        credentialStore = secretservice
        helper = /usr/local/bin/git-credential-libsecret
    [credential "https://github.com"]
          username = akdor1154
    [includeif "gitdir:~/src/mywork/"]
          path=~/src/mywork/.gitconfig

~/src/mywork/.gitconfig:

    [user]
        email = "12345+akdor1154-mywork@users.noreply.github.com"
        signingkey = ~/.ssh/id_rsa.mywork.private
    [credential "https://github.com"]
        username = akdor1154-mywork

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.

Do you REALLY use ~/Work/Code/Repos path? even with CDPATH configured I would use lowercase folders. I'm just a console/terminal user :D

I wrote about this too https://lesterzone.github.io/blog/2023/01/10/git-work-person...

I consider this type of 'tips' hidden gems

MacOS’s case insensitive filesystem makes the point moot, if the OP is on that platform. But it makes me wince too!

Autocomplete can make this moot too

Interesting, but why not just configure direnv to set appropriate env vars based on your current directory? That works for more than just git.

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.

I love how the internet collectively discovers obscure git config and writes about it.

I wrote this about 3 or 4 years ago detailing exactly the same: https://www.leemeichin.com/posts/conditional-git-config.html

Does anyone know what is the equivalent for TortoiseGit in Windows?

What path should go into gitdir if the repos are at S:\Repos\ ?

Not an equivalent, but I use "Git Extensions", and am very happy with it.

I think Git on Windows uses forward slashes, but colon is retained, like this:

    directory = C:/Program Files (x86)/MyProject

https://gitextensions.github.io

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...)

This is how git works, it's just an exe, so it must work like that I think.

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.

I only do work stuff on the work laptop so the git config is entirely separate from my personal one since its on a totally separate machine

I use this for contributing between multiple OSS projects. For Google projects I use a specific e-mail and sign all commits with it.

Amazing! This is so helpful for anyone building open source, wanting to avoid committing with the work email by mistake.

Thanks

This great, but not supported by all IDEs. JGit for example didn’t support includeIf last time I checked.

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.

The typical use case, as in TFA, is for customizing username and email, so at least commit is already out.

Other than different personal/work email and username, which config do you set differently?

I use virtual machines for development.

Why downvotes? It is the most effective way to separate config. If any of those "condition" fails, you may nuke or compromise your repo!

> 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.

[1]: That's literally what they are for.

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.

Oh this is pretty useful! Thanks!

Actually useful, thanks

Reply on news.ycombinator.com