6 ms·

How I configure my Git identities

439 points by 8organicbits 2y ago

quectophoton 2y ago
Eh, if I need a different identity[1], I just use a different identity[2] (ideally different machine or host when feasible). I'm not a fan of mixing identities, like for example mixing a personal identity[2] with a work identity[1]. [1]: Git. [2]: OS user.
r0rshrk 2y ago
This works well enough for me with minimal configuration https://github.com/TheYkk/git-switcher https://github.com/TheYkk/git-switcher
est 2y ago
you don't have to mess with ~/.ssh/config Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article) [core] sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a This makes submodules easy without the `insteadOf`
- airtonix 2y ago
  [dead]
- duskwuff 2y ago
  And if you have more than one SSH identity?
  - dgfitz 2y ago
    Sounds like a different problem.
    - hinkley 2y ago
      You're missing the fact that if you are going to use git and also ssh into places, you should learn to use the ssh config file. Yes, there are other ways to do it. Just as there are other ways to enter a building besides just opening the door. It's the one tool that works consistently across multiple projects.
      - dgfitz 2y ago
        Wait, ssh has a config file?! And I should learn about it!? lol, you’re an ass
        hinkley 2y ago
        I’ve spent too much of my career picking up after people like you.
        dgfitz 2y ago
        You haven’t. That’s cool though, I can understand your frustration.
  - est 2y ago
    You can also put that in your includeIf confs. I updated the parent comment
vishnugupta 2y ago
I really liked the website, the layout, typography, icons etc. Really well done!
- ndjdjddjsjj 2y ago
  Especially the TLD
  - phito 2y ago
    The whole domain name for me, my childhood dog was named Benji :) ... time to go change my security questions
elric 2y ago
The includeIf stuff is pretty neat. I currently keep the SSH complexity in ~/.ssh, where I have several includes, one for each customer|project|identity. Things without unique hostnames, like github, get an alias assigned: Host customer-github Hostname github.com IdentityFile ~/.ssh/customer_rsa User git All I have to do is use the alias in any git clone command and I'm done.
- dolmen 2y ago
  I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities: https://github.com/dolmen/github-keygen https://github.com/dolmen/github-keygen
bilalq 2y ago
So glad I clicked on this link. I was already doing the `includeIf: "gitdir"` thing to separate work and personal stuff, but `hasconfig:remote` is a total game-changer.
- meitham 2y ago
  absoluelty! I can't believe this treasure was hidden as a draft for three years!
bentinata 2y ago
I use `insteadOf` instead of ssh alias because my workplace use GitLab orgs. So instead of typing the full URL like: git clone gitlab.com/acme-corp/project-name I could use: git clone work:project-name But this kinda broke `includeIf` since it store the `insteadOf` remote url directly. I then had to convert existing repositories to use the `insteadOf` url. I wrote a little bit about it here: https://bentinata.com/log/git-insteadof-includeif https://bentinata.com/log/git-insteadof-includeif
pestaa 2y ago
Is there a risk with not using different keys for work and personal? The private bits are all in the same place: if one is compromised, so are the rest.
- dns_snek 2y ago
  If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all. However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.
- x3n0ph3n3 2y ago
  Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.
  - pestaa 2y ago
    Interesting! Curious though that the compliance rules are strict enough it warrants distinct keypairs, but not that strict for the devs to use dedicated hardware.
    - x3n0ph3n3 2y ago
      It's not a compliance rule that requires different keypairs. It's just that GitHub doesn't support using the same keypair for different GitHub users. If you have a GitHub Enterprise user for internal code development, that GitHub Enterprise user is restricted from interacting outside of the GitHub Enterprise/ If you also need to contribute to OSS projects as part of your job, you have to use a different GitHub user, and therefore a different keypair.
- dolmen 2y ago
  About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job. Your signing key for personal projects probably has a different temporality.
powersnail 2y ago
I do something similar, but instead of `insteadOf`, I just clone the repo with `gh-work:org/repo`, and in the git config: [includeIf "hasconfig:remote.*.url:gh-work:**/**"] path = ~/.gitconfig.d/gh-work.inc So, any git repo cloned with the ssh identity defined under `gh-work` will take on the config of `gh-work.inc`, which includes the git identity, and also the same signing key as in the ssh config. Essentially, the name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.
- shaicoleman 2y ago
  Please note that includeIf is case sensitive, and the order of precedence is last one wins. To check if it's working correctly you can run: git remote get-url origin git config --get user.email
- qmmmur 2y ago
  In my experience scripts that expect your remote to be a certain way will break with this approach.
  - powersnail 2y ago
    I don't really use a lot of script that wraps git; but so far the two things I do use---lazygit and github cli---don't have problems with this approach. Github CLI can identify the correct corresponding repo on Github, and also can choose the right user account associated with this repo if there are more than one authenticated user. I mean, it seems to me that any script that tries to do something with git remote URL, should deal with any string that git thinks is a valid remote URL. `ssh-host-name:owner/repo` is not exactly an edge case.
- TeMPOraL 2y ago
  Thank you. The article left me uneasy, in OCD sense, about the solution having more degrees of freedom than it needs. I was wondering how to trim it down to one runtime parameter, and yours is an elegant way to do it.
cquintana92 2y ago
Shameless plug for a tool I developed in order to easily switch git identities based on projects: https://github.com/cquintana92/git-switch-user https://github.com/cquintana92/git-switch-user After configuring the identities you just need to run $ git su Personal $ git su Work And all the identity configuration (email, name, SSH key and optionally PGP key) will be set up into the repo's .git/config file. Saved me a ton of time.
- dolmen 2y ago
  Shameless plug for a tool I developed in order to easily manage GitHub identities for Git access via SSH: https://github.com/dolmen/github-keygen https://github.com/dolmen/github-keygen 12 years old, but still actively maintained.
ku1ik 2y ago
This post is a great reference of what’s possible with git config wrt includes/remotes, and I’m sure I’ll be getting back to it. One thing though: what’s the point of using separate keys for work/personal/github/gitlab? I fail to see a practical and security advantage over using one key (per workstation).
- gloflo 2y ago
  Privacy for sure. It's no ones business to know how certain accounts are related.
  - ku1ik 2y ago
    Ah, right. E.g. using separate GH accounts for personal and work. Forgot about that!
- carbonboarder 2y ago
  GitHub does not allow you to share a key with another GitHub account anymore
  - computerfriend 2y ago
    They never did. The account is identified by the key, so it's impossible.
  - ku1ik 2y ago
    Of course! I’ve been using separate GH accounts for work and personal stuff in the past myself. It’s been years since then and I completely forgot. In fact, I was one of not too many who used separate account for work, and people didn’t understand it, wondering why the hassle.
- ku1ik 2y ago
  To add to my other replies to replies in this thread… These days I prefer to use local VMs to compartmentalize different areas of work (personal, consulting, etc) so my git config is plain and simple. Lately I’ve been doing mostly consulting work around open-source so I’ve been using my primary GH account for the most part, but separate VMs allow me to use a different key (account) without advanced git config incantations.
jmb99 2y ago
As cool as this is, how many peoples' employers allow them to do either personal work from the work computers, or work work from their personal computers? My company is quite strict on both.
- that_guy_iain 2y ago
  I've not had a single employer care. For many of the companies that I've worked at, the laptops were taken home to be used as personal computers at the end of the day and this was a well-known thing and I was often looked at weird when I said I had another laptop. One time I took the wrong laptop in and had to work on my personal laptop in the office. It wasn't so much fun that day.
- TeMPOraL 2y ago
  There's a third use case: multiple identities at work. In my case, company I worked for got acquired by a larger corp. Things happening as they usually do, I ended up having two different e-mails/identities/SSO credentials - me@old.company and me@new.corp. Most of the code I worked on was stuck on old company's infra, but new repos were developed on the acquiring corp's infra, so for years, I had to maintain two different SSH / Git identities too, and use appropriate one for a given repo.
bobek 2y ago
I've been using `includeIf` with directory for ages (https://www.bobek.cz/til/git-identities/ https://www.bobek.cz/til/git-identities/), the `hasconfig:remote` is really neat. And it also works when cloning the repository.
computerfriend 2y ago
This is a nice trick. But if you: * use a dedicated work machine and * also want to version control your dotfiles (including ~/.config/git/) and * don't want to leak your work repository organisation via your dotfiles, you can instead add something like [include] path = work.gitconfig which will override any settings above it and also fail gracefully/silently if work.gitconfig does not exist.
- redak 2y ago
  What would work.gitconfig include in this case?
  - computerfriend 2y ago
    A work-specific email address and PGP key.
cabirum 2y ago
user.useconfigonly=true can also help
asadjb 2y ago
I hated configuring multiple Hosts/aliases in my ~/.ssh/config for Github/Bitbucket when dealing with different keys for different clients. I ended up creating a "SSH environment" manager 4 years ago to help with this: https://github.com/theonejb/sshenv https://github.com/theonejb/sshenv It's worked wonderfully for me since then, and it's something I use almost daily.
guthriej 2y ago
Thank you for this! I have exactly the same problem and was waiting for the solution to present itself, which it now has. Aside: I use NixOS with home-manager (on linux and mac), which makes this trivial [1]. Added the following lines to my home-manager config: programs.git = { enable = true; ... includes = [ { condition = "hasconfig:remote.*.url:git@github.com:<work>/**"; contents = { user.email = "<work email>"; }; } ]; } [1]: https://nix-community.github.io/home-manager/options.xhtml#opt-programs.git.includes https://nix-community.github.io/home-manager/options.xhtml#o...
- SpaceNugget 2y ago
  That certainly looks less trivial than writing it directly in your .gitconfig file. It's the same condition and setting as what's in the article, but now with a build/templating stage and a new programming language to learn with unusual syntax.
  - guthriej 2y ago
    Agree on your comment re build/templating and new language. Nix is weird and NixOS is complicated. Nonetheless I have convinced myself that I like it. In TFA the author must set up two configurations: the .gitconfig, and the file which is included in the .gitconfig. Home-manager does this automatically through one config parameter. That is what I was pleased with and wanted to share.
  - necovek 2y ago
    While I don't use NixOS or home-manager, I would imagine this provides some extra value: i.e. config is versioned or easy to move between machines. Curiosity got the better of me so I looked it up at https://nix-community.github.io/home-manager/ https://nix-community.github.io/home-manager/ and it indeed does purport to provide benefits I guessed at and then some. Whether that's better than just manually managing things yourself is altogether a different matter.
dmos62 2y ago
Why have multiple git identities in the same machine? I use a single different key with each machine and that's it.
- nicholassmith 2y ago
  I use different accounts for my work GitHub and my personal GitHub, so this approach would be great if I shared a machine for both of them to keep separation.
  - wink 2y ago
    I find the premise to be potentially wrong already. Is a `dotfiles` repo personal? I don't usually push to my own repos from my work machines, but I do want to pull and push config updates while not disclosing my work email there or rewrite commits all the time (it's not secret, I just don't want it there).
- buro9 2y ago
  I use a unique account with every distinct git org / github org that I interact with. Even if I'm in my work profile and I need to do something in an org called `acmecorp`, I will create @acmecorp-identifier to do that. This is just a very long experience... * Security policies for work things have a blast radius of just that employer * OSS things have a lifetime beyond the life of an employment / contract * Source control elsewhere (GitHub / GitLab / Bitbucket / Gitea / Forgejo / etc) all has a local blast radius, and if a provider / org forces changes (roll your keys!) then the impact is limited to just that provider * When something changes ownership (i.e. an org), the impact to me is low It seems much more sane. I think of a single git identity across multiple orgs as a bit of a smell.
deleted 2y ago
[deleted]
stared 2y ago
> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it. I suddenly felt a deep connection with the author. It is not only me. I promise you, my dear drafts, that one day, I will set you free to see the world!
er453r 2y ago
One even-better approach IMHO Just keep a .gitconfig in your HOME with aliases for your identities. Then just after initializing/cloning the repo do git config-company or git config-personal er453r@r7:~$ cat ~/.gitconfig [user] useConfigOnly = true [alias] config-personal = !echo CONFIG-PERSONAL && \ git config --local user.email 'personal@email.com' && \ git config --local user.name 'personal' && \ git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_personal' config-company = !echo OLD CONFIG-COMPANY && \ git config --local user.email 'official@comapny.io' && \ git config --local user.name 'Name Surname' && \ git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_company'
- flumpcakes 2y ago
  How would you do the initial clone without the correct ssh config to begin with? I think the benefit of the article's method is that any clone from their org will just work.
  - kreetx 2y ago
    I have something like the parent suggests and yes, the article's idea is better because you don't need to do anything manual nor remember to run your own command at all.
  - er453r 2y ago
    You are right - that first clone has to be manually preceded by GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_personal" - but after this you just configure the repo and forget about it. I just like this workflow better since it is totally directory/remote agnostic (compared to the article). Just use whatever suits you best :)
    - cweagans 2y ago
      You don't need to specify your key file like that if you've got your keys loaded into an SSH agent. Or even better, IMO: use 1Password or similar that can both store your keys securely _and_ can be used directly as an SSH agent. That way, your SSH keys never need to be stored on disk in the first place.
codazoda 2y ago
I love that Rek drew the image on your about page. I knew I recognized their work as soon as I saw it. Based on that and your 1.44MB Club, you might find Neat CSS interesting. :P https://neat.joeldare.com https://neat.joeldare.com My Neat CSS websites will almost always fit on a floppy and I have a case of old floppies right here in my closet. The Neat CSS home page is only about 12k. Things get bigger when you start adding images, of course.
cimnine 2y ago
I've written a short blogpost about how to link SSH Keys to Git identities: https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-in-a-git-repo/ https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-i...
andrei-akopian 2y ago
> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it. Did you say that just so we could imagine the world where you published it earlier? Thanks anyway, and nice site!
lijok 2y ago
I always strongly advise consultants to use a separate machine for work, or at the very least a separate OS user. You’re risking putting yourself in a whole lot of trouble by using a personal machine for work.
- deleted 2y ago
  [deleted]
- necovek 2y ago
  Using a "personal machine for work" is a very wide gamut of situations (eg. at one remote-first company, we were expected to provide our own laptops, and got extra money every 2-3 years to buy a new one, but they were always our "personal" laptops even if the company contributed to paying them off; or what if you are a temporary contractor; or...). Care to elaborate in what circumstances is it a problem and why? Edit: I mostly asked the parent poster to provide more context and avoid general assertions like "a whole lot of trouble". Risks are indeed tangible, but if we are unable to enumerate them, we are mostly spreading FUD instead of educating.
  - Sardtok 2y ago
    Mixing personal and work data in the same directories on disk can be an issue. Requires extra work to cleanly separate private stuff and confidential work stuff.
    - necovek 2y ago
      This is still very general, and in opposition to the previous advice. A solution to this seems to be "use separate directories", not "use separate machines".
      - sshine 2y ago
        Using separate directories does not guarantee proper deletion.
montroser 2y ago
I used to work at a startup with a character who would set his identity to be random fairytale-sounding nonsense, changing every day. So his commits on Monday would be attributed to Mr. Bunnymann, and Tuesday would be Doctor Funtime, etc. It was super unhelpful when trying to do version control forensics. But if I'm being generous, I think maybe he was trying to remind everyone that anyone can put anything in their identity config, and we shouldn't trust whatever is in there for all that much.
- spacemanspiff01 2y ago
  Did he use the same signing key? (If we are being generous)
  - kevindamm 2y ago
    I don't think you can -- the key's identity needs to match the name/comment/email it was generated with. You would have to regenerate after every name change to have them all verified (and keep them all in file with the got server afterwards, too).
    - TeMPOraL 2y ago
      > needs to match the name/comment/email Is that "/" an "and", or an "or"? I'd expect only e-mail has to match, leaving you free to change the user name.
    - tecleandor 2y ago
      I'd say that in general it verifies it with the email, but it depends. I just did a test with four commits with a signature matching both on user and email, only on email, only on user, and in none of them and: From GitHub, it validates signatures with the email registered in the commit: If the signature matches the key registered for the GitHub user with that email address, it says "Verified" in a green box. If it doesn't , it says "Unverified" in a yellow box. So GitHub "Verified" two commits: the one that matches all the fields and the one that only matches the email. From git CLI, it depends on your configuration. If you do a `git log --show-signature` at first it will complain with `error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification`. You need to set up a file with your trusted ssh signatures. Once you set that up, it will verify ALL correctly signed commits, even if they don't match the commit email address. Seems like the signature and the commit can have different emails, so to speak: "commited by fake@email.com and signed by real@email.com. The signature is valid by real@email.com". Example I did, changing the email addresses: git show --show-signature 11906e1 commit 11906e14155ae08b7e7e23f26aa9c04913ade5dd Good "git" signature for good@email.com with ED25519 key SHA256:9uU6+7pNNzwVEKTecpJE4Bmm2WXaqZXMZRLe9rJZ0ZY Author: fake name <fake@email.com> Date: Mon Nov 25 13:36:28 2024 +0100
ab71e5 2y ago
Great tips, did not know about the `hashconfig:remote` option. Currently dealing with a difficult setup where we have subrepos (so just using an `~/.ssh/config` alias for github.com:org does not work), some dependencies downloaded with CMake CPM, and working in a vscode devcontainer.
layer8 2y ago
Be careful what client you use, though. JGit unfortunately still doesn’t support includeIf.
deleted 2y ago
[deleted]
zelphirkalt 2y ago
Somewhat annoying, that the configuration is spread out across 2 config files of 2 separate programs (git and ssh) and that the `insteadOf` `url` must match the `Host` in `.ssh/config`, which leaves a lot of room for mistakes and is fiddly, but at least this method works well! Edit: Hmm it seems to ask me over and over again for my password for a key at every pull or push. Maybe this method somehow disables memorizing the SSH identity?
zelphirkalt 2y ago
Why does the page redirect me periodically to https://www.benji.dog/%F0%9F%8D%AA/ https://www.benji.dog/%F0%9F%8D%AA/ and hide its content?
metabeard 2y ago
I prefer to split work and personal repos into ~/dev for work and ~/src for personal. # file ~/.gitconfig [includeIf "gitdir:~/src/"] path = /Users/metabeard/.config/git/.gitconfig-personal [includeIf "gitdir:~/dev/"] path = /Users/metabeard/.config/git/.gitconfig-work and # file .config/git/.gitconfig-personal and .config/git/.gitconfig-work # both are very similar with different email and signingkey [user] name = Meta Beard email = email@metabeard.me signingkey = ssh-rsa xxx== [gpg] format = ssh [gpg "ssh"] program = "/Applications/1Password.app/Contents/MacOS/op-ssh-sign" [commit] gpgsign = true
- deleted 2y ago
  [deleted]

439 points by 8organicbits 2y ago

Eh, if I need a different identity[1], I just use a different identity[2] (ideally different machine or host when feasible). I'm not a fan of mixing identities, like for example mixing a personal identity[2] with a work identity[1]. [1]: Git. [2]: OS user.

r0rshrk 2y ago

This works well enough for me with minimal configuration https://github.com/TheYkk/git-switcher https://github.com/TheYkk/git-switcher

est 2y ago

you don't have to mess with ~/.ssh/config Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article) [core] sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a This makes submodules easy without the `insteadOf`

airtonix 2y ago
[dead]
duskwuff 2y ago
And if you have more than one SSH identity?
- dgfitz 2y ago
  Sounds like a different problem.
  - hinkley 2y ago
    You're missing the fact that if you are going to use git and also ssh into places, you should learn to use the ssh config file. Yes, there are other ways to do it. Just as there are other ways to enter a building besides just opening the door. It's the one tool that works consistently across multiple projects.
    - dgfitz 2y ago
      Wait, ssh has a config file?! And I should learn about it!? lol, you’re an ass
      - hinkley 2y ago
        I’ve spent too much of my career picking up after people like you.
        dgfitz 2y ago
        You haven’t. That’s cool though, I can understand your frustration.
- est 2y ago
  You can also put that in your includeIf confs. I updated the parent comment

vishnugupta 2y ago

I really liked the website, the layout, typography, icons etc. Really well done!

ndjdjddjsjj 2y ago
Especially the TLD
- phito 2y ago
  The whole domain name for me, my childhood dog was named Benji :) ... time to go change my security questions

elric 2y ago

The includeIf stuff is pretty neat. I currently keep the SSH complexity in ~/.ssh, where I have several includes, one for each customer|project|identity. Things without unique hostnames, like github, get an alias assigned: Host customer-github Hostname github.com IdentityFile ~/.ssh/customer_rsa User git All I have to do is use the alias in any git clone command and I'm done.

dolmen 2y ago
I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities: https://github.com/dolmen/github-keygen https://github.com/dolmen/github-keygen

bilalq 2y ago

So glad I clicked on this link. I was already doing the `includeIf: "gitdir"` thing to separate work and personal stuff, but `hasconfig:remote` is a total game-changer.

meitham 2y ago
absoluelty! I can't believe this treasure was hidden as a draft for three years!

bentinata 2y ago

I use `insteadOf` instead of ssh alias because my workplace use GitLab orgs. So instead of typing the full URL like: git clone gitlab.com/acme-corp/project-name I could use: git clone work:project-name But this kinda broke `includeIf` since it store the `insteadOf` remote url directly. I then had to convert existing repositories to use the `insteadOf` url. I wrote a little bit about it here: https://bentinata.com/log/git-insteadof-includeif https://bentinata.com/log/git-insteadof-includeif

pestaa 2y ago

Is there a risk with not using different keys for work and personal? The private bits are all in the same place: if one is compromised, so are the rest.

dns_snek 2y ago
If both of your keys are on the same computer they would most likely be compromised simultaneously, or not at all. However if you're worried about this then you should probably be using a hardware token anyway - something that supports SSH authentication via FIDO2, GPG, or smart card interface.
x3n0ph3n3 2y ago
Your key cannot be tied to more than one identity, and if you use GitHub Enterprise, your work identity may be restricted from contributing to repos outside of the Enterprise. This is to prevent cloning private code into public spaces. For this reason, you need to have separate keys.
- pestaa 2y ago
  Interesting! Curious though that the compliance rules are strict enough it warrants distinct keypairs, but not that strict for the devs to use dedicated hardware.
  - x3n0ph3n3 2y ago
    It's not a compliance rule that requires different keypairs. It's just that GitHub doesn't support using the same keypair for different GitHub users. If you have a GitHub Enterprise user for internal code development, that GitHub Enterprise user is restricted from interacting outside of the GitHub Enterprise/ If you also need to contribute to OSS projects as part of your job, you have to use a different GitHub user, and therefore a different keypair.
dolmen 2y ago
About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job. Your signing key for personal projects probably has a different temporality.

powersnail 2y ago

I do something similar, but instead of `insteadOf`, I just clone the repo with `gh-work:org/repo`, and in the git config: [includeIf "hasconfig:remote.*.url:gh-work:**/**"] path = ~/.gitconfig.d/gh-work.inc So, any git repo cloned with the ssh identity defined under `gh-work` will take on the config of `gh-work.inc`, which includes the git identity, and also the same signing key as in the ssh config. Essentially, the name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.

shaicoleman 2y ago
Please note that includeIf is case sensitive, and the order of precedence is last one wins. To check if it's working correctly you can run: git remote get-url origin git config --get user.email
qmmmur 2y ago
In my experience scripts that expect your remote to be a certain way will break with this approach.
- powersnail 2y ago
  I don't really use a lot of script that wraps git; but so far the two things I do use---lazygit and github cli---don't have problems with this approach. Github CLI can identify the correct corresponding repo on Github, and also can choose the right user account associated with this repo if there are more than one authenticated user. I mean, it seems to me that any script that tries to do something with git remote URL, should deal with any string that git thinks is a valid remote URL. `ssh-host-name:owner/repo` is not exactly an edge case.
TeMPOraL 2y ago
Thank you. The article left me uneasy, in OCD sense, about the solution having more degrees of freedom than it needs. I was wondering how to trim it down to one runtime parameter, and yours is an elegant way to do it.

cquintana92 2y ago

Shameless plug for a tool I developed in order to easily switch git identities based on projects: https://github.com/cquintana92/git-switch-user https://github.com/cquintana92/git-switch-user After configuring the identities you just need to run $ git su Personal $ git su Work And all the identity configuration (email, name, SSH key and optionally PGP key) will be set up into the repo's .git/config file. Saved me a ton of time.

dolmen 2y ago
Shameless plug for a tool I developed in order to easily manage GitHub identities for Git access via SSH: https://github.com/dolmen/github-keygen https://github.com/dolmen/github-keygen 12 years old, but still actively maintained.

ku1ik 2y ago

This post is a great reference of what’s possible with git config wrt includes/remotes, and I’m sure I’ll be getting back to it. One thing though: what’s the point of using separate keys for work/personal/github/gitlab? I fail to see a practical and security advantage over using one key (per workstation).

gloflo 2y ago
Privacy for sure. It's no ones business to know how certain accounts are related.
- ku1ik 2y ago
  Ah, right. E.g. using separate GH accounts for personal and work. Forgot about that!
carbonboarder 2y ago
GitHub does not allow you to share a key with another GitHub account anymore
- computerfriend 2y ago
  They never did. The account is identified by the key, so it's impossible.
- ku1ik 2y ago
  Of course! I’ve been using separate GH accounts for work and personal stuff in the past myself. It’s been years since then and I completely forgot. In fact, I was one of not too many who used separate account for work, and people didn’t understand it, wondering why the hassle.
ku1ik 2y ago
To add to my other replies to replies in this thread… These days I prefer to use local VMs to compartmentalize different areas of work (personal, consulting, etc) so my git config is plain and simple. Lately I’ve been doing mostly consulting work around open-source so I’ve been using my primary GH account for the most part, but separate VMs allow me to use a different key (account) without advanced git config incantations.

jmb99 2y ago

As cool as this is, how many peoples' employers allow them to do either personal work from the work computers, or work work from their personal computers? My company is quite strict on both.

that_guy_iain 2y ago
I've not had a single employer care. For many of the companies that I've worked at, the laptops were taken home to be used as personal computers at the end of the day and this was a well-known thing and I was often looked at weird when I said I had another laptop. One time I took the wrong laptop in and had to work on my personal laptop in the office. It wasn't so much fun that day.
TeMPOraL 2y ago
There's a third use case: multiple identities at work. In my case, company I worked for got acquired by a larger corp. Things happening as they usually do, I ended up having two different e-mails/identities/SSO credentials - me@old.company and me@new.corp. Most of the code I worked on was stuck on old company's infra, but new repos were developed on the acquiring corp's infra, so for years, I had to maintain two different SSH / Git identities too, and use appropriate one for a given repo.

bobek 2y ago

I've been using `includeIf` with directory for ages (https://www.bobek.cz/til/git-identities/ https://www.bobek.cz/til/git-identities/), the `hasconfig:remote` is really neat. And it also works when cloning the repository.

computerfriend 2y ago

This is a nice trick. But if you: * use a dedicated work machine and * also want to version control your dotfiles (including ~/.config/git/) and * don't want to leak your work repository organisation via your dotfiles, you can instead add something like [include] path = work.gitconfig which will override any settings above it and also fail gracefully/silently if work.gitconfig does not exist.

redak 2y ago
What would work.gitconfig include in this case?
- computerfriend 2y ago
  A work-specific email address and PGP key.

cabirum 2y ago

user.useconfigonly=true can also help

asadjb 2y ago

I hated configuring multiple Hosts/aliases in my ~/.ssh/config for Github/Bitbucket when dealing with different keys for different clients. I ended up creating a "SSH environment" manager 4 years ago to help with this: https://github.com/theonejb/sshenv https://github.com/theonejb/sshenv It's worked wonderfully for me since then, and it's something I use almost daily.

guthriej 2y ago

Thank you for this! I have exactly the same problem and was waiting for the solution to present itself, which it now has. Aside: I use NixOS with home-manager (on linux and mac), which makes this trivial [1]. Added the following lines to my home-manager config: programs.git = { enable = true; ... includes = [ { condition = "hasconfig:remote.*.url:git@github.com:<work>/**"; contents = { user.email = "<work email>"; }; } ]; } [1]: https://nix-community.github.io/home-manager/options.xhtml#opt-programs.git.includes https://nix-community.github.io/home-manager/options.xhtml#o...

SpaceNugget 2y ago
That certainly looks less trivial than writing it directly in your .gitconfig file. It's the same condition and setting as what's in the article, but now with a build/templating stage and a new programming language to learn with unusual syntax.
- guthriej 2y ago
  Agree on your comment re build/templating and new language. Nix is weird and NixOS is complicated. Nonetheless I have convinced myself that I like it. In TFA the author must set up two configurations: the .gitconfig, and the file which is included in the .gitconfig. Home-manager does this automatically through one config parameter. That is what I was pleased with and wanted to share.
- necovek 2y ago
  While I don't use NixOS or home-manager, I would imagine this provides some extra value: i.e. config is versioned or easy to move between machines. Curiosity got the better of me so I looked it up at https://nix-community.github.io/home-manager/ https://nix-community.github.io/home-manager/ and it indeed does purport to provide benefits I guessed at and then some. Whether that's better than just manually managing things yourself is altogether a different matter.

dmos62 2y ago

Why have multiple git identities in the same machine? I use a single different key with each machine and that's it.

nicholassmith 2y ago
I use different accounts for my work GitHub and my personal GitHub, so this approach would be great if I shared a machine for both of them to keep separation.
- wink 2y ago
  I find the premise to be potentially wrong already. Is a `dotfiles` repo personal? I don't usually push to my own repos from my work machines, but I do want to pull and push config updates while not disclosing my work email there or rewrite commits all the time (it's not secret, I just don't want it there).
buro9 2y ago
I use a unique account with every distinct git org / github org that I interact with. Even if I'm in my work profile and I need to do something in an org called `acmecorp`, I will create @acmecorp-identifier to do that. This is just a very long experience... * Security policies for work things have a blast radius of just that employer * OSS things have a lifetime beyond the life of an employment / contract * Source control elsewhere (GitHub / GitLab / Bitbucket / Gitea / Forgejo / etc) all has a local blast radius, and if a provider / org forces changes (roll your keys!) then the impact is limited to just that provider * When something changes ownership (i.e. an org), the impact to me is low It seems much more sane. I think of a single git identity across multiple orgs as a bit of a smell.

deleted 2y ago

[deleted]

stared 2y ago

> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it. I suddenly felt a deep connection with the author. It is not only me. I promise you, my dear drafts, that one day, I will set you free to see the world!

er453r 2y ago

One even-better approach IMHO Just keep a .gitconfig in your HOME with aliases for your identities. Then just after initializing/cloning the repo do git config-company or git config-personal er453r@r7:~$ cat ~/.gitconfig [user] useConfigOnly = true [alias] config-personal = !echo CONFIG-PERSONAL && \ git config --local user.email 'personal@email.com' && \ git config --local user.name 'personal' && \ git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_personal' config-company = !echo OLD CONFIG-COMPANY && \ git config --local user.email 'official@comapny.io' && \ git config --local user.name 'Name Surname' && \ git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_company'

flumpcakes 2y ago
How would you do the initial clone without the correct ssh config to begin with? I think the benefit of the article's method is that any clone from their org will just work.
- kreetx 2y ago
  I have something like the parent suggests and yes, the article's idea is better because you don't need to do anything manual nor remember to run your own command at all.
- er453r 2y ago
  You are right - that first clone has to be manually preceded by GIT_SSH_COMMAND="ssh -i ~/.ssh/id_rsa_personal" - but after this you just configure the repo and forget about it. I just like this workflow better since it is totally directory/remote agnostic (compared to the article). Just use whatever suits you best :)
  - cweagans 2y ago
    You don't need to specify your key file like that if you've got your keys loaded into an SSH agent. Or even better, IMO: use 1Password or similar that can both store your keys securely _and_ can be used directly as an SSH agent. That way, your SSH keys never need to be stored on disk in the first place.

codazoda 2y ago

I love that Rek drew the image on your about page. I knew I recognized their work as soon as I saw it. Based on that and your 1.44MB Club, you might find Neat CSS interesting. :P https://neat.joeldare.com https://neat.joeldare.com My Neat CSS websites will almost always fit on a floppy and I have a case of old floppies right here in my closet. The Neat CSS home page is only about 12k. Things get bigger when you start adding images, of course.

cimnine 2y ago

I've written a short blogpost about how to link SSH Keys to Git identities: https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-in-a-git-repo/ https://brainfood.xyz/post/20241030-use-a-specific-ssh-key-i...

andrei-akopian 2y ago

> Note: I've had this post drafted for 3 YEARS!!! It's finally time to publish it. Did you say that just so we could imagine the world where you published it earlier? Thanks anyway, and nice site!

lijok 2y ago

I always strongly advise consultants to use a separate machine for work, or at the very least a separate OS user. You’re risking putting yourself in a whole lot of trouble by using a personal machine for work.

deleted 2y ago
[deleted]
necovek 2y ago
Using a "personal machine for work" is a very wide gamut of situations (eg. at one remote-first company, we were expected to provide our own laptops, and got extra money every 2-3 years to buy a new one, but they were always our "personal" laptops even if the company contributed to paying them off; or what if you are a temporary contractor; or...). Care to elaborate in what circumstances is it a problem and why? Edit: I mostly asked the parent poster to provide more context and avoid general assertions like "a whole lot of trouble". Risks are indeed tangible, but if we are unable to enumerate them, we are mostly spreading FUD instead of educating.
- Sardtok 2y ago
  Mixing personal and work data in the same directories on disk can be an issue. Requires extra work to cleanly separate private stuff and confidential work stuff.
  - necovek 2y ago
    This is still very general, and in opposition to the previous advice. A solution to this seems to be "use separate directories", not "use separate machines".
    - sshine 2y ago
      Using separate directories does not guarantee proper deletion.

montroser 2y ago

I used to work at a startup with a character who would set his identity to be random fairytale-sounding nonsense, changing every day. So his commits on Monday would be attributed to Mr. Bunnymann, and Tuesday would be Doctor Funtime, etc. It was super unhelpful when trying to do version control forensics. But if I'm being generous, I think maybe he was trying to remind everyone that anyone can put anything in their identity config, and we shouldn't trust whatever is in there for all that much.

spacemanspiff01 2y ago
Did he use the same signing key? (If we are being generous)
- kevindamm 2y ago
  I don't think you can -- the key's identity needs to match the name/comment/email it was generated with. You would have to regenerate after every name change to have them all verified (and keep them all in file with the got server afterwards, too).
  - TeMPOraL 2y ago
    > needs to match the name/comment/email Is that "/" an "and", or an "or"? I'd expect only e-mail has to match, leaving you free to change the user name.
  - tecleandor 2y ago
    I'd say that in general it verifies it with the email, but it depends. I just did a test with four commits with a signature matching both on user and email, only on email, only on user, and in none of them and: From GitHub, it validates signatures with the email registered in the commit: If the signature matches the key registered for the GitHub user with that email address, it says "Verified" in a green box. If it doesn't , it says "Unverified" in a yellow box. So GitHub "Verified" two commits: the one that matches all the fields and the one that only matches the email. From git CLI, it depends on your configuration. If you do a `git log --show-signature` at first it will complain with `error: gpg.ssh.allowedSignersFile needs to be configured and exist for ssh signature verification`. You need to set up a file with your trusted ssh signatures. Once you set that up, it will verify ALL correctly signed commits, even if they don't match the commit email address. Seems like the signature and the commit can have different emails, so to speak: "commited by fake@email.com and signed by real@email.com. The signature is valid by real@email.com". Example I did, changing the email addresses: git show --show-signature 11906e1 commit 11906e14155ae08b7e7e23f26aa9c04913ade5dd Good "git" signature for good@email.com with ED25519 key SHA256:9uU6+7pNNzwVEKTecpJE4Bmm2WXaqZXMZRLe9rJZ0ZY Author: fake name <fake@email.com> Date: Mon Nov 25 13:36:28 2024 +0100

ab71e5 2y ago

Great tips, did not know about the `hashconfig:remote` option. Currently dealing with a difficult setup where we have subrepos (so just using an `~/.ssh/config` alias for github.com:org does not work), some dependencies downloaded with CMake CPM, and working in a vscode devcontainer.

layer8 2y ago

Be careful what client you use, though. JGit unfortunately still doesn’t support includeIf.

deleted 2y ago

[deleted]

zelphirkalt 2y ago

Somewhat annoying, that the configuration is spread out across 2 config files of 2 separate programs (git and ssh) and that the `insteadOf` `url` must match the `Host` in `.ssh/config`, which leaves a lot of room for mistakes and is fiddly, but at least this method works well! Edit: Hmm it seems to ask me over and over again for my password for a key at every pull or push. Maybe this method somehow disables memorizing the SSH identity?

zelphirkalt 2y ago

Why does the page redirect me periodically to https://www.benji.dog/%F0%9F%8D%AA/ https://www.benji.dog/%F0%9F%8D%AA/ and hide its content?

metabeard 2y ago

I prefer to split work and personal repos into ~/dev for work and ~/src for personal. # file ~/.gitconfig [includeIf "gitdir:~/src/"] path = /Users/metabeard/.config/git/.gitconfig-personal [includeIf "gitdir:~/dev/"] path = /Users/metabeard/.config/git/.gitconfig-work and # file .config/git/.gitconfig-personal and .config/git/.gitconfig-work # both are very similar with different email and signingkey [user] name = Meta Beard email = email@metabeard.me signingkey = ssh-rsa xxx== [gpg] format = ssh [gpg "ssh"] program = "/Applications/1Password.app/Contents/MacOS/op-ssh-sign" [commit] gpgsign = true

deleted 2y ago
[deleted]