[joshbode]

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 bitbucket.org exec "[[ ${PWD}/ == ${HOME}/repos/personal/* ]]"
      IdentityFile ~/.ssh/keys/personal
      User me

[dig1]

Nice trick! I'd usually set alias in ~/.ssh/config and set origin to match that alias, e.g.

    Host project-foo
    Hostname github.com
      User git
      IdentityFile ~/.ssh/some_key

Then I'll pull the project with:

    git clone project-foo:/Foo/project.git

[crabbone]

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?

[Joker_vD]

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.

[crabbone]

Are you talking about server-side configuration or client-side?

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.

[Joker_vD]

Client-side, of course. My password manager stores SSH keys and integrates with SSH seamlessly (it implements an ssh-agent), which took about 10 minutes to set up; I spent about an hour trying to integrate it with Git's own credential system to provide username-password pairs for HTTPS access and couldn't do it. So there.

[crabbone]

Well, nowadays the popular managed Git services provide you with a simple way of setting up HTTPS access: you go to some page that generates an "auth token" or something along those lines, depending on the service you use, and they give you the line you should put in your ~/.git-credentials file.

But even if they don't, here's an example for Bitbucket (we use self-hosted Bitbucket at work):

    https://$USER:$PASSWORD@bitbucket.$COMPANY.com%3a$PORT

and then in ~/.gitconfig

    [credential]
 helper = store

The ~/.git-credentials file may contain multiple lines, and it doesn't have the same problem with escaping as, say, ~/.netrc (because stuff that goes into it needs to be URL-encoded). Also, unlike SSH, it can use password-based authentication (you cannot put your SSH password into ~/.ssh/config). So, this solves the part where you want to authenticate to different Git repos.

And if you want to use different personalities for authenticating to the same repo, you can change the location of the ~/.git-credentials file per repo. I was never in a situation where I had more than two roles in the same repo, so, usually, I'd alternate between the global .git-credentials and local-to-repo one. If it becomes really annoying, I'd have two checkouts of the same repo, but with credentials configured for different users.

PS. I would never use a password manger because of trust issues. I don't like random programs having weird integrations with it. Plus, it usually fails to understand the context in which password is to be supplied (eg. tries to show a pop-up window where pop-ups don't work). I store the information I want to be secret encrypted with GPG with a key with a passphrase. I use Emacs to keep a buffer with this file open, if I need passwords and copy from it when necessary. This is less automated and takes extra few seconds to do things that require authentication, but having once lost my password manager database to an upgrade... I'm once burned twice shy.

[Joker_vD]

Or you can go to some another page, upload a public key, and then they also tell you that you should put such and such lines into your ~/.ssh/config file.

And no, I am not going to store passwords, or auth tokens, in an unencrypted plain text file thank you very much.

[hprotagonist]

> (you cannot put your SSH password into ~/.ssh/config)

you can, however, use `ssh-agent` (and should!)

[Hackbraten]

I avoid HTTPS for Git because I prefer not to have credential secrets sitting around unencrypted in my home directory. For SSH, I keep my private key on my Yubikeys.