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

Organizing multiple Git identities

garrit.xyz

Post reply on HN
Print view View original

81–90 of 92 posts

Re: Organizing multiple Git identities

#81

Post by avgcorrection »

firloop wrote: post #14

> This trick has simplified my project onboarding quite a bit. No more "You forgot to update your Email Address" requests from clients! Does this happen in practice? Most commits on professional git repos that I work on are of the form @users.noreply.github.com.

I think the noreply email behavior on Github is a bit strange. I commit with my newer email. Then it gets merged to the upstream I was making a pull request in. Then it seems that the committer's (me) email is that noreply email. And then my author email gets rewritten to my old email (the one registered on GitHub first—but both are registered on GitHub). (Why does it much with my emails... I'm just wondering out loud.)

Re: Organizing multiple Git identities

#82

Post by KronisLV »

l72 wrote: post #3

How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: Host github-client1 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client1 Host github-client2 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client2 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?

> How do people handle multiple git identities with github+ssh?

Perhaps not the answer you're expecting (mentioning this anyways, because perhaps it'll be useful/interesting to some folks), but I just ended up paying for GitKraken and suddenly managing multiple accounts (not just GitHub, but also my self-hosted Gitea instance and other servers) became as easy as choosing a different value in a dropdown: https://www.gitkraken.com/blog/managing-mulitple-github-acco...

Paying for something like a Git client felt silly, but at the same time it's good, does what I need and runs on every playform that I use, while also not annoying me too much, same as with JetBrains IDEs and something like MobaXTerm. Before that I used SourceTree and Git Cola because some operations are more convenient with a GUI instead of a CLI, though they didn't have that functionality.

Re: Organizing multiple Git identities

#83

Post by jomar »

avgcorrection wrote: post #81
firloop wrote: post #14

> This trick has simplified my project onboarding quite a bit. No more "You forgot to update your Email Address" requests from clients! Does this happen in practice? Most commits on professional git repos that I work on are of the form @users.noreply.github.com.

I think the noreply email behavior on Github is a bit strange. I commit with my newer email. Then it gets merged to the upstream I was making a pull request in. Then it seems that the committer's (me) email is that noreply email. And then my author email gets rewritten to my old email (the one registered on GitHub first—but both are registered on GitHub). (Why does it much with my emails... I'm just wondering out lou…

Probably the older email address is still the primary one for the GitHub account.

GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See https://github.com/isaacs/github/issues/1368> for the tedious details.

Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they will set noreply@github as the committer so that they can sign the merged commit themselves, and set author name & email to what they have recorded for the GH account involved (and the signature is then a record that GH have verified that account's involvement).

Personally I think it is shocking that they ignore the name and email address that the actual author of the commit has selected. This is both a violation of the author's intentions -- for example, you may set work and personal email addresses in different repositories as discussed here, but GitHub will rewrite them all to the same thing when other people press "Squash and Merge" on your pull requests -- and potentially a doxxing security risk.

I have considered re-reporting this to GitHub via the newer community discussions or via support again, but given the extent to which they've ignored all such reports over the last five years it is hard to find the motivation to do so.

Re: Organizing multiple Git identities

#84

Post by rgoulter »

l72 wrote: post #3

How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: Host github-client1 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client1 Host github-client2 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client2 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?

FWIW, note that the `User git` in your config means that you don't need `git@` in the clone command.

Re: Organizing multiple Git identities

#86

Post by dataflow »

stevefan1999 wrote: post #85

I also want this, but on a folder level I have a github.com folder with all the repos I cloned from GH but I always have to type git config user.name/email before committing. It's so annoying at this point.

You could try overriding 'git' in your PATH with a shell script wrapper that prepends something like -c user.name=yourname before the rest of the command, or that runs git config if it hasn't been run yet, etc. (whatever makes sense for your case)

Re: Organizing multiple Git identities

#87

Post by vindex10 »

atoav wrote: post #80
vindex10 wrote: post #47

Earlier quoted context omitted.

thanks for the suggestion. I haven't used agent forwarding myself. I read a bit in the manual, and this seems to have a problem if the users I'm sharing the machine with have `sudo`: > Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's UNIX-domain socket) can access the local agent through the forwarded connection. An attacker cannot…

Exactly. This should be used with care on remote hosts that are untrusted. But for local development it is still superior to not having a password at all.

for local development, I use keychain [1] on top of the ssh-agent.

this allows to keep ssh-agent On for a limited time, so it will ask for password again in, for example, 10 minutes.

[1] https://www.funtoo.org/Funtoo:Keychain

Re: Organizing multiple Git identities

#88

Post by Wicher »

l72 wrote: post #3

How do people handle multiple git identities with github+ssh? Since you always log in as the `git` user, you can't reuse keys. I end up with an ~/.ssh/config like: Host github-client1 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client1 Host github-client2 Hostname github.com User git IdentityFile ~/.ssh/id_rsa-client2 Then clone using `git clone git@github-client1:username/repo.git` Is there a better way?

It's what I've been doing up to now, but dealing with git submodules is very painful this way :-( The includeIf approaches on gitdir or remote URL are better in that respect.

Re: Organizing multiple Git identities

#90

Post by avgcorrection »

jomar wrote: post #83
avgcorrection wrote: post #81

Earlier quoted context omitted.

I think the noreply email behavior on Github is a bit strange. I commit with my newer email. Then it gets merged to the upstream I was making a pull request in. Then it seems that the committer's (me) email is that noreply email. And then my author email gets rewritten to my old email (the one registered on GitHub first—but both are registered on GitHub). (Why does it much with my emails... I'm just wondering out lou…

Probably the older email address is still the primary one for the GitHub account. GitHub took it upon themselves to change email addresses and author names when merging via the UI buttons like "Squash and Merge" in 2018 and then again in 2019. See https://github.com/isaacs/github/issues/1368 > for the tedious details. Essentially the post-2019 behaviour seems to be that where possible with "Squash and Merge" they wil…

Thank you for the explanation and link. I'll have to look into that some more.

It's definitely very dissapointing that GitHub will just change the commit metadata like that. I'm not strongly tied to GitHub right now so I might end up looking somewhere else for similar services.

Post reply on HN