Live data from Hacker News

How I configure my Git identities

benji.dog

21–30 of 113 posts

Re: How I configure my Git identities

#21

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.

Re: How I configure my Git identities

#22
post #19

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

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

Re: How I configure my Git identities

#23
post #5

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

Re: How I configure my Git identities

#25
post #14

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.

Re: How I configure my Git identities

#26
post #14

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.

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.

Re: How I configure my Git identities

#27
post #24

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.

Re: How I configure my Git identities

#29
post #19

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

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

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

Re: How I configure my Git identities

#30
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.
Post reply on HN