| ▲ | flumpcakes 3 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 3 months ago | parent | next [-] |
| 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 3 months ago | parent | prev [-] |
| 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 :) |
| |
| ▲ | nixosbestos 3 months ago | parent | next [-] | | The same exact config you'd have to replicate for the OP's solution is what you'd have to replicate as well. It also means your config is semi-copied into every repo instead of being centrally managed. This is like the worst of all options, idgi. I'm sorry, I don't want to be mean but this has got to be the worst way Ive seen someone try to solve this. I want to cry skimming it. Why would anyone do this and think it's simpler? Wew, gotta just leave this one alone. | |
| ▲ | cweagans 3 months ago | parent | prev [-] | | You don't need to specify your key file like that if you've got your keys loaded into an SSH agent. Or even better, IMO: use 1Password or similar that can both store your keys securely _and_ can be used directly as an SSH agent. That way, your SSH keys never need to be stored on disk in the first place. |
|
