51–60 of 73 posts
I didn't want to have to organize my work and personal repos using a directory structure, so I use matching on the remote instead. Since my job uses a GitHub organization, I'm able to conditionally include a config file that uses my work email in any GitHub repo under that organization. I wrote it up here, if that sounds useful: https://www.brantonboehm.com/code/conditional-git-config/
I use virtual machines for development.
For local Linux projects, I have Docker images for my development environments, one per identity. So I keep my PC as minimal as I can, while the compilers, interpreters, etc, are only installed within a Docker image.
Then I go to a project's directory, run a helper command like `identity1-workspace`, and it (1) starts the Docker container for `identity1`, (2) mounts the current directory to `/workspace` within the container, and (3) also mounts some cache directories, etc.
For other hosts where I don't want to use Docker (e.g. in Raspberry Pis, or in VPS) I just have multiple users and SSH into the one I want to use.
I can do this because I just use nvim and the terminal for everything, so for me there's basically no difference between developing "natively" vs developing inside a Docker container vs developing through SSH. The only difference is whether I run the command `nvim` vs `identity1-workspace` vs `ssh identity1`[1], respectively.
All this sounds like too much work, but I'd rather use (1) Docker, or (2) `adduser` and `ssh`, because those I can do from memory and can trust to be reliable since `identity1` can't push to repos of `identity2` even by accident. In comparison, the article's `includeIf` looks like something that could easily leak an identity by accident, not to mention that I'd forget its syntax after 2 days.
[1]: Well in this case also have to then `cd somewhere ; nvim` because writing a helper for this is no big deal.
Thanks
I use virtual machines for development.
Why downvotes? It is the most effective way to separate config. If any of those "condition" fails, you may nuke or compromise your repo!
Maybe it was unusual enough that it didn't sound like a serious response (?), but you're completely right that the article's suggested solution can easily leak stuff by accident if you want to absolutely avoid committing with the wrong identity, thus revealing name, email, timezone, or some other metadata, in a repository where you don't want to.
If I contribute to a legal-gray-area anime fansub I don't want those people (other contributors) to know anything about my IRL identity, for example, so of course I'd reduce the possibility of info leaks due to typos or because my muscle memory betrayed me.
Like I mentioned in a sibling reply, I'd rather use a completely different OS user[1], a Docker container, or a different host.
[1]: That's literally what they are for.
Another trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is the "Match exec" directive which allows you to include a shell (bash) conditional (such as a directory-check), e.g. Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/work/* ]]" IdentityFile ~/.ssh/keys/work User me-work Match originalhost bitbuc…
Host project-foo
Hostname github.com
User git
IdentityFile ~/.ssh/some_key
git clone project-foo:/Foo/project.gitAnother trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is the "Match exec" directive which allows you to include a shell (bash) conditional (such as a directory-check), e.g. Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/work/* ]]" IdentityFile ~/.ssh/keys/work User me-work Match originalhost bitbuc…
Genuinely curios. After HTTPS became supported I never looked back. The whole authentication management and Git remote URL syntax are a huge mess I'd never want to touch unless forced to. HTTPS makes it a lot simpler... at least for me. Am I missing something?
Earlier quoted context omitted.
Why downvotes? It is the most effective way to separate config. If any of those "condition" fails, you may nuke or compromise your repo!
> Why downvotes? It is the most effective way to separate config. If any of those "condition" fails, you may nuke or compromise your repo! Maybe it was unusual enough that it didn't sound like a serious response (?), but you're completely right that the article's suggested solution can easily leak stuff by accident if you want to absolutely avoid committing with the wrong identity, thus revealing name, email, timezon…
Another trick I find useful for managing Git over SSH for multiple accounts (especially with bitbucket.org, which supports specifying different usernames) is the "Match exec" directive which allows you to include a shell (bash) conditional (such as a directory-check), e.g. Match originalhost bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/work/* ]]" IdentityFile ~/.ssh/keys/work User me-work Match originalhost bitbuc…
What's the reason to want SSH over HTTPS for Git? Genuinely curios. After HTTPS became supported I never looked back. The whole authentication management and Git remote URL syntax are a huge mess I'd never want to touch unless forced to. HTTPS makes it a lot simpler... at least for me. Am I missing something?
This great, but not supported by all IDEs. JGit for example didn’t support includeIf last time I checked.
Earlier quoted context omitted.
What's the reason to want SSH over HTTPS for Git? Genuinely curios. After HTTPS became supported I never looked back. The whole authentication management and Git remote URL syntax are a huge mess I'd never want to touch unless forced to. HTTPS makes it a lot simpler... at least for me. Am I missing something?
I personally never managed to make pushes work over HTTPS, while with SSH it works the moment clone/pull works. Plus I vaguely remember that setting up HTTP auth was way more cumbersome that SSH auth.
I haven't had to set up Git server in a very long time. I'm not even sure if I had to set up HTTPS authentication for it. But, I can see how this may be potentially more difficult as you'd already have SSH set up for accessing the server by the time you get to set up Git.
It's been a lot easier on the client-side though. Especially having to deal with multiple users / multiple servers and having to share configuration between different machines. Usually it just boils down to having ~/.git-credentials and if necessary, adding a similar file in the root of the repo.