Readit News logoReadit News
powersnail · 9 months ago
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 name `gh-work` becomes the distinguishing element in both my ssh identity and my git identity, and I find this easier to think about.

TeMPOraL · 9 months ago
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.
shaicoleman · 9 months ago
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

qmmmur · 9 months ago
In my experience scripts that expect your remote to be a certain way will break with this approach.
powersnail · 9 months ago
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.

er453r · 9 months ago
One even-better approach IMHO

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

    er453r@r7:~$ cat ~/.gitconfig 
    [user]
        useConfigOnly = true
    [alias]
        config-personal = !echo CONFIG-PERSONAL && \
            git config --local user.email 'personal@email.com' && \
            git config --local user.name 'personal' && \
            git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_personal'
        config-company = !echo OLD CONFIG-COMPANY && \
            git config --local user.email 'official@comapny.io' && \
            git config --local user.name 'Name Surname' && \
            git config --local core.sshCommand 'ssh -i ~/.ssh/id_rsa_company'

flumpcakes · 9 months ago
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.
kreetx · 9 months ago
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.
er453r · 9 months ago
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).

Just use whatever suits you best :)

montroser · 9 months ago
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.

necovek · 9 months ago
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.

Ferret7446 · 9 months ago
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.
helloooooooo · 9 months ago
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.
spacemanspiff01 · 9 months ago
Did he use the same signing key? (If we are being generous)
kevindamm · 9 months ago
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).
edejong · 9 months ago
People paid him for such nonsense?
7bit · 9 months ago
The service came at no additional cost
est · 9 months ago
git has built in support to separate author and committer I believe he/she is just changing the author property.
est · 9 months ago
you don't have to mess with ~/.ssh/config

Just put this in your ~/.gitconfig (or ~/.config/git/personal as in the article)

  [core]
      sshCommand = /usr/bin/ssh -o IdentitiesOnly=yes -i ~/.ssh/IdentityFile2 -a

This makes submodules easy without the `insteadOf`

duskwuff · 9 months ago
And if you have more than one SSH identity?
est · 9 months ago
You can also put that in your includeIf confs. I updated the parent comment
dgfitz · 9 months ago
Sounds like a different problem.

Dead Comment

bobek · 9 months ago
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.
elric · 9 months ago
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.

dolmen · 9 months ago
I have created a tool 12 years ago (still actively maintained) to manage multiple GitHub SSH identities:

https://github.com/dolmen/github-keygen

guthriej · 9 months ago
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:<work>/**";
        contents = {
          user.email = "<work email>";
        };
      }
    ];
  }

[1]: https://nix-community.github.io/home-manager/options.xhtml#o...

SpaceNugget · 9 months ago
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.
necovek · 9 months ago
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.

guthriej · 9 months ago
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.

bilalq · 9 months ago
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.
meitham · 9 months ago
absoluelty! I can't believe this treasure was hidden as a draft for three years!