Live data from Hacker News

How I configure my Git identities

benji.dog

101–110 of 113 posts

Re: How I configure my Git identities

#101

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…

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

Re: How I configure my Git identities

#102
post #10
post #6

Earlier quoted context omitted.

And if you have more than one SSH identity?

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.

Re: How I configure my Git identities

#103

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: /**"; contents = { user.email = " "; }; } ]; } [1]: htt…

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.

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.

Re: How I configure my Git identities

#104
post #25

Earlier quoted context omitted.

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.

Re: How I configure my Git identities

#106
post #87
post #83

Earlier quoted context omitted.

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.

Re: How I configure my Git identities

#107
post #10

Earlier quoted context omitted.

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

Re: How I configure my Git identities

#108

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…

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

Re: How I configure my Git identities

#109
post #107

Earlier quoted context omitted.

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.

Re: How I configure my Git identities

#110

Earlier quoted context omitted.

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 d…

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