Shameless plug of a tool I wrote for managing multiple git identities: https://github.com/cquintana92/git-switch-user
Organizing multiple Git identities
71–80 of 92 posts
Re: Organizing multiple Git identities
#72Earlier quoted context omitted.
That is a nice trick. I've had my main email address in .config/git/config, added an override in ./.git/config for projects that need it, and checked who I am from time to time with [alias] whoami = "!f() { echo $(git config --get user.name)' '; }; f" but I might switch to your less error-prone approach.
Try: git var GIT_AUTHOR_IDENT
Handy, but is it really easier to type? Or as pleasantly reminiscent of one of the first Unix commands you ever learnt, back in the days when they actually really were multiuser machines? :-)
Re: Organizing multiple Git identities
#73I found this a few years ago at https://stackoverflow.com/questions/14754762/can-gitconfig-o... and has been my preferred setup.
Re: Organizing multiple Git identities
#74Earlier quoted context omitted.
Different gitconfigs per path on disk, git automatically uses the right identity depending on where you are on disk. Allows you to separate all projects into different users and every repository within those directories will use the specified user. Main/default config (~/.gitconfig): [user] email = git@victor.earth name = Victor Bjelkholm [includeIf "gitdir:/home/user/projects/user-a/"] path = /home/user/.gitconfig-u…
Note that includeIf support can still be spotty in third-party tools/IDEs. Be sure to check that it works everywhere you need it to.
Last I looked, Xcode still doesn't support this. Having it present in the .gitconfig breaks SPM for initial clones and updates.
Re: Organizing multiple Git identities
#75And here I am modifying each .git/config by hand like a pleb
That's also where the `git config` command gets/sets things by default when you don't pass --global.
Re: Organizing multiple Git identities
#76Earlier quoted context omitted.
Different gitconfigs per path on disk, git automatically uses the right identity depending on where you are on disk. Allows you to separate all projects into different users and every repository within those directories will use the specified user. Main/default config (~/.gitconfig): [user] email = git@victor.earth name = Victor Bjelkholm [includeIf "gitdir:/home/user/projects/user-a/"] path = /home/user/.gitconfig-u…
You can also filter based on the remote URL! I find this much more useful than the location of the directory on disk. ; include only if a remote with the given URL exists (note ; that such a URL may be provided later in a file or in a ; file read after this file is read, as seen in this example) [includeIf "hasconfig:remote.*.url:https://example.com/\*"] path = foo.inc [remote "origin"] url = https://example.com/git*
Great tip!
But how could I also select the config for an initial clone of a repo based on the repository address?
Re: Organizing multiple Git identities
#77Earlier quoted context omitted.
I was doing this, and sent a question to Github support for a particular thing I was trying to do with my multiple accounts. I got a fairly strong warning about how I was in violation of their service agreement and I could get my subscription terminated if I was found to be using multiple accounts. It was very odd. Either (a) the person responding to me was uninformed, or (b) that's actually Github's policy and it's…
It's not allowed: > One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine). https://docs.github.com/en/site-policy/github-terms/github-t... I suppose you could pay for additional accounts though. Anyways, I would use SSH host aliases for this myself as well. Might want to consider `Identitie…
In context of parent post, I wonder if people realize github is not where git things come from...
"if you choose to control a machine account as well, that's fine, but it can only be used for running a machine"
I'm not aware that "running a machine" has a legal definition. I think it's fine, if you have a corporate account and a private email you are probably fine. I think they mainly have that as some sort of rate limiting legalese, to prevent abuse from "account hopping" i.e. abusing the github api or spamming, etc..
If your work account is a "legal entity", i.e. it is a person under corporate personhood laws, this definition also doesn't really hold water (both you and the corporation account count as legal persons, so this doesn't do much, other than the cost of an incorporation being non-zero). Just don't do weird things with your separate accounts, and actually keep them separate, and you're probably fine.
Re: Organizing multiple Git identities
#78Earlier quoted context omitted.
It's always been very clear in their Terms of Service (which obviously everyone reads carefully...): The third bullet point at https://docs.github.com/en/site-policy/github-terms/github-t... -- > One person or legal entity may maintain no more than one free Account (if you choose to control a machine account as well, that's fine, but it can only be used for running a machine). This is the primary reason why I have on…
Having said that, given that many people do use separate GitHub accounts for their separate private and work personas, and many organisations seemingly expect their employees to do so, perhaps GitHub could consider revising this Terms of Service restriction to better reflect reality. There have also been times when I would like to have access to a second GitHub account for testing purposes. (In particular, for testin…
I maintain two but my personal account is a Pro account.
I imagine some large number of folks that have two accounts are Pro on at at least one of them, if not both.
Re: Organizing multiple Git identities
#79nixos solves private keys and tools switch easy.
for folders, i ended up with overlays.
just follow origin upstream remote locally so that http and file united.
i mean if remote is https github com slash dzmitry lahoda slash web3.nix
than local is /home/dz/github com slash dzmitry lahoda slash web3.nix
navigation is easy. forks easy. no project1 or client 1. just navigation overlay. same works for consumption of knowledge and learning.
one may do codespace with nix easy too or many local homes.
nix and path overlays is superior and easy to maintain.
nix makes remote, local, ci, codespace, user switch, depending on dlmany versions of same repo super easy.
even by unix idiots like me.
that not full schema so. there are tags and data properties (security, size, files count, uniquiness of copy).
so decide if store local or remo only, git and syncthing same time, torrent and syncthing, gdrive and git, keepass and syncthing, what devices, ipfs. any combo.
tags when overlays (forced hierarchy fail). when git forks, than many remotes with overlay following most active fork.
that approach partially fixes some of my mental issue i guess. oh, i want to install zfs to fix duplication.
hardware keys for security i use also. thesd days can mix same key, but held ssh, crypto, aws creds on same device.
Re: Organizing multiple Git identities
#80Earlier quoted context omitted.
> Disadvantage is that you have to enter password each time you push/pull. Run ssh-add in your terminal session before doing your push/pull dance — this way you only have to enter the password once. This gives you the security of the password protected key without bothering you too much in practise. If you need to pull on a remote that doesn't have your private keys (as is good and proper) you can run ssh -A foo@bar.…
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.