in .gitconfig, you say:
name = Me Myself
email = email@example.com
signingkey = D34DB44F
path = ~/.gitconfig_work
name = Me Myself
email = firstname.lastname@example.org
signingkey = D34DC0D4
sshCommand = ssh -i ~/.ssh/work_ed25519
IANAL but I would strongly suggest everyone to only use their employer issued computer to do work related work and move all their personal, hobby projects into their own personal computer, unless you don't care your employer owning the copyright of your personal hobby projects.
You want to work on your personal project before going home, bring your laptop to work with you, go to a coffee shop (off-property) and work there.
That said, when I’m doing PRs for open source, it gets a bit awkward to use my work ID. If I have permission to contribute to dependencies on work time (which has definitely not always been the case), then something like this could be useful.
Contributing to OSS isn’t just about fixing a problem for my company. I could do that internally. It’s about fixing a problem for everybody, including future me.
This means that there is no default email set, and that git will error if you try and commit, because there is no email set.
I do a lighter weight version of this article by just doing the above. Then when I do the first commit in a repo, I get that error and I do the following command:
git config --local user.email email@example.com
(or the my personal email as appropriate). Then I have per repo config that persists unless I blow the repo away completely.
- requiring a user to be set
- not having one filled in the global settings
The upside is that even if the folder is moved, the user config still applies. The downside is that you have to set it per repository (but only once).
There are pros and cons, but I don't see one being any better or worse than the other in absolute terms.
If some current (or future) coworker has a question about the code, I don't want them to necessarily e-mail me on my home account. I might not be checking it during work hours, or I might not even be with the company anymore.
Similarly, if someone actually wants to contact my e-mail for a hobby-project, I don't want them to send it to my work-account, which over time I might no longer have access to anyway.
Also, some people prefer to not disclose their employer on GitHub hobby projects (or at all on the web). Simiarly, your employer doesn't necessarily need to know about every hobby project you start (as long as you're not violating work-contract clauses).
The notifications don't go to the email in the git commit.
Since I usually have to work on several repositories, I usually do what OP presented. I have one directory per client with each their own configuration and their repositories.
Now for every client i set up a separate VMWare Workstation virtual machine with all the relevant git config files, ssh keys, software and build dependencies etc.
That way every client is compartmentalized and there is limited chance of data or code leaking between clients. And i can always mid-session put the VM on pause, switch to another client and then resume right where i left, with all the editor windows open and services running.
I call it the container approach to workspaces.
without modifying the root `~/.gitconfig` file.