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.
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.
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
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).
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.
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.
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'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.
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.
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.
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.
To check if it's working correctly you can run:
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.
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
I just like this workflow better since it is totally directory/remote agnostic (compared to the article).
Just use whatever suits you best :)
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.
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.
Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article)
This makes submodules easy without the `insteadOf`Dead Comment
https://github.com/dolmen/github-keygen
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:
[1]: https://nix-community.github.io/home-manager/options.xhtml#o...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.
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.