Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How I configure my Git identities

benji.dog

Post reply on HN
Print view View original

61–70 of 113 posts

Re: How I configure my Git identities

#61

Post by TeMPOraL »

jmb99 wrote: 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.

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.

Re: How I configure my Git identities

#62

Post by heywire »

tonyedgecombe wrote: post #43
pestaa wrote: 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.

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.

Re: How I configure my Git identities

#63

Post by necovek »

SpaceNugget wrote: post #49
guthriej wrote: post #36

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.

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.

Re: How I configure my Git identities

#64

Post by Ferret7446 »

montroser wrote: post #50

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

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.

Re: How I configure my Git identities

#65

Post by Sardtok »

necovek wrote: post #60
lijok wrote: post #48

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…

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.

Re: How I configure my Git identities

#66

Post by ab71e5 »

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.

Re: How I configure my Git identities

#67

Post by kroltan »

necovek wrote: post #60
lijok wrote: post #48

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…

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

Re: How I configure my Git identities

#68

Post by necovek »

notpushkin wrote: post #38
dolmen wrote: post #26

Earlier quoted context omitted.

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.

Re: How I configure my Git identities

#69

Post by helloooooooo »

Ferret7446 wrote: post #64
montroser wrote: post #50

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

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.

No, the previous commenter is saying that you cannot trust the identity provided in commits period. This has nothing to do with trusting employees, rather placing trust in the identity in commit.

Re: How I configure my Git identities

#70

Post by necovek »

Sardtok wrote: post #65
necovek wrote: post #60

Earlier quoted context omitted.

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…

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