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.

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.

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

In my experience scripts that expect your remote to be a certain way will break with this approach.

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.

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'

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.

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.

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

The same exact config you'd have to replicate for the OP's solution is what you'd have to replicate as well. It also means your config is semi-copied into every repo instead of being centrally managed. This is like the worst of all options, idgi.

I'm sorry, I don't want to be mean but this has got to be the worst way Ive seen someone try to solve this. I want to cry skimming it. Why would anyone do this and think it's simpler? Wew, gotta just leave this one alone.

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.

If yours was a "blameless culture", when you did "version control forensics", you didn't really care about who did it, but when it happened and around what other changes (to understand the broader context)? Right? (Though obviously, it helps to know who did something so you can ask them directly if they remember more details, or so you know what to expect when it comes to style and expertise :)

Anyway, if you simply[1] require commits to be signed with GPG, and enlist what GPG identities are acceptable, you are pretty much set (and you can instead rely on the signature instead of the author/committer metadata to identify the actual author).

[1] "Simply" and GPG signing don't always go hand-in-hand, I admit.

You should trust it as much as you trust any document written/signed by your employees. Which is to say, if you can't trust your employees to not properly identify their commits, you should fire them.

This is true in general internet, but workplaces are normally more high-trust. If one needs to guard themselves against hacking by their co-worker, they have less time and energy to do actual work.

So a fiction character is maaybe OK, as long as it is clearly fictional name and no one else in the company does that; but other stuff, like actually impersonating other co-workers would be very bad, and should eventually leave to firing.

Did he use the same signing key? (If we are being generous)

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

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

Thanks for the correction. I know I've had GitHub invalidate my credentials before for a mismatch but I didn't know it was only the email that's relevant.

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

People paid him for such nonsense?

The service came at no additional cost

git has built in support to separate author and committer I believe he/she is just changing the author property.

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`

And if you have more than one SSH identity?

You can also put that in your includeIf confs. I updated the parent comment

Sounds like a different problem.

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.

Wait, ssh has a config file?! And I should learn about it!?

lol, you’re an ass

I’ve spent too much of my career picking up after people like you.

You haven’t. That’s cool though, I can understand your frustration.

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

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.

I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities:

https://github.com/dolmen/github-keygen

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

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.

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

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.

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.

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

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.

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.

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.

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

Using separate directories does not guarantee proper deletion.

Using separate laptops does not guarantee proper deletion. Not sure what your point is?

(Contractual terms between an employee/contractor and employer/company is what ensures there is no abuse for the most part)

I should say:

Using separate directories makes improper deletion likely.

Using separate computers with full-disk encryption and shredding procedures makes proper deletion a happy path.

It's not that you cannot properly isolate environments on a single computer.

It's that a single computer is, unless you're a Qubes/BSD/Hypervisor fanatic, not very isolated at all.

So if/when your personal computer gets compromised because of a browser zero-day, your work's intellectual property is potentially compromised.

When you combine that with likely not deleting files properly (or at all), the window of opportunity for IP theft is much bigger.

When you further add the complete unlikeliness that former employees/contractors will report that their personal computers were compromised after having neglected to properly purge your intellectual property, the case for buying your employees/contractors dedicated machinery becomes a no-brainer. Simply from a corporate risk perspective.

It's not a practical problem, but a principal + legal problem.

I fully agree it's a legal problem, which is what my point was from the beginning — depending on the circumstances, it might apply to you or not.

Companies both have to have a set of "processes" in place for legal/compliance reasons, and an employee is liable if they do something that's outside the recommended practice (like using a personal device when forbidden by such policies).

Still, the focus should be on liability and ensuring compliance with legal terms, and an employee needs to make sure they do that. In some cases, that's easier done with a separate computer. In others (when there is no direct spelled-out requirement), downsides of using a separate device outweight the benefits of making compliance with legal terms easier.

As a side note, a browser zero-day is probably even more likely to target work computers, so that example is pretty bad — company data remaining on personal devices by accident is where the problem really is.

Personal machine as in a machine that you use for anything other than work for that particular client.

The same goes for putting anything personal on a company issued device, such as signing into your private email.

It is a problem in all circumstances. The problems may not always manifest, but if they do, you’ll be in deep trouble.

Problems range from the mild; company has mandatory tooling that takes control of your machine. To the extreme; offices get raided and equipment seized indiscriminately.

General assertions are fine. The exercise of whether to follow them up with research is left as an exercise to the reader.

- Endpoint monitoring software may compromise more than it strictly needs to;

- If you're a contractor, risk of leaking other clients' assets (running `tree` in the wrong folder while screensharing or more subtle variations);

- Shredder policy, done with the work = destroy hardware (though I don't think companies with shredder policy would incentivise personal laptops, you never know)

If it's a personal laptop, I would assume there is no "endpoint monitoring software" installed.

When it comes to "assets", companies make a big fuss about leaking them, but in reality, it's totally irrelevant. I.e. witness Windows OS source code being leaked: Microsoft wasn't affected at all. Leaking short/mid-term plans would probably have a bigger effect (abuse on the stock market, beating a competitor to the market on their big bet...).

You would assume wrong, many (asshat) employers require them, so much that I actually have to screen that kind of sillyness when interviewing. Works a treat to filter out toxic workplaces, but exists nontheless.

As for leaking assets, maybe it does not affect the company at large, but that literally does not matter for this discussion. It will definitely affect your relationship, most often negatively.

And in any case, my usage of assets was clearly general, substitute the example for "clicking on the wrong stored tab while screensharing" can just as well lead you to leaking a plan.

There are certainly "milder ways" to put it, but the tone one uses is certainly on the author.

For example, please let me know of any one's company leaked source code and how someone has used that to their advantage and become amazingly successful in the same market?

What does this have to do with work device management? Are you seriously suggesting using a personal device for work, despite the asset leakage risk, and relying on "it doesn't matter" as recourse if that risk were to materialize?

Those are unrelated claims. The fact that "it doesn't matter" for a company (which you called me delusional on, yet don't support it in any way) and the fact that there are companies with more lax personal-device policy.

So nope: I am saying that not all companies have the same policies, nor the same risks, and that this is a legal liability that totally depends on the terms of engagement.

> Care to elaborate in what circumstances is using a "personal machine for work" a problem and why?

When you stop working for an employer/customer and you are legally required to purge all files.

Having everything work-related on a dedicated machine makes purging all files very easy.

Not having everything work-related on a dedicated machine makes purging all files questionable.

Ok, so one circumstance is when there is a "legal requirement to purge all files". That's certainly not "always" and not always as hard: one of my jobs was at an open source company, and there are plenty of those to go around these days; as a consultant, you may start with some base work to build off of that you keep the rights to as well...

This also assumes you never-ever used a personal device to access any of them either (they might be in caches or Trash/Recycle Bin) — and I agree that to satisfy such a legal requirement, you probably don't want to be using a personal device to access them at all.

Keeping things separate has some upsides, but also some downsides (multiple devices to lug around) — depending on their situation, everybody should choose their own compromise (granted, some engagement contracts will make that choice for you).

I've personally come to be very happy with hardware isolation as a method of mental compartmentalization.

E.g. choice of computer dictates choice of activity, I won't accidentally work on something when I'm not supposed to.

I've had paid-for open source gigs, and I have a bunch of open source work spread out on a bunch of machines.

Downsides are:

  - The bag gets heavy when I have multiple events for separate customers/events on the same day
  - For stuff that is shared between computers (e.g. open source projects), I can forget to git push

I've tried to put my machines on the same VPN for some convenience wrt. file sync.

Fortunately, the most locked off machines never need for other computers to connect to them.

And yes, this came as a customer requirement, but I've decided to grow with the choice.

I don't trust process isolation on a single computer very much.

Shameless plug for a tool I developed in order to easily switch git identities based on projects: 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.

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

12 years old, but still actively maintained.

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

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.

What would work.gitconfig include in this case?

A work-specific email address and PGP key.

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

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

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

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.

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.

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.

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.

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.

There is also a risk using the same machine for work and personal. I’d address that first.

Right? I can’t believe how many people seemingly use the same machine for both.

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.

> About signing keys, it would make sense stopping using a signing key (marking it as such and deleting it) once you stop a job.

What does this achieve exactly?

Nobody can steal it and sign it with your key for a commit to appear as if it was signed by a regular committer to a work project that would pass the verification if there is any on the repo or CI/CD side (if that's not restricting keys by the time period). The scenario is certainly a bit far-fetched and contorted, but it is possible.

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

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

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

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.

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?

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

It's worked wonderfully for me since then, and it's something I use almost daily.

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

Privacy for sure. It's no ones business to know how certain accounts are related.

Ah, right. E.g. using separate GH accounts for personal and work. Forgot about that!

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.

GitHub does not allow you to share a key with another GitHub account anymore

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.

They never did. The account is identified by the key, so it's impossible.

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.

This works well enough for me with minimal configuration

https://github.com/TheYkk/git-switcher

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.

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.

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.

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

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.

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.

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

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

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

Especially the TLD

The whole domain name for me, my childhood dog was named Benji :)

... time to go change my security questions

user.useconfigonly=true can also help

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.