Repository navigation
git_protocol not respected when adding remote for fork #2711
Description
Activity
@MarijnS95 Thanks for detailing your use-case. Some people have asked to be able to have configuration for the preferred clone protocol be separate from the configuration for the preferred push protocol. It sounds like that is what you would benefit from as well. Do you agree?
I'm coming here with the same reasoning for
gh repo create. I've configuredgit_protocoltosshbutgh repo createadds the remote with thehttpsprotocol. That doesn't seems to make sense to me? At the very least as @MarijnS95 suggests we should have a way of controlling this with a flag or so.@driesvints Yeah, a bump to this issue would be nice. Reordering the precedence as per my suggestion is trivial. I have in fact forgotten about this open issue entirely after patching it locally and continuing my day.
I could perhaps submit that as as a draft PR?
@MarijnS95 that would be amazing. Thanks for that!
I need to retract my phrasing. It seems that
gh repo createdoes respect thegit_protocolsettings. Apologies, I should have double checked this.What I'm actually looking for is for a way to force the protocol to be
sshsincehttpsprompts people for their password/username. That leads to issues with automation. So a--protocolflag would be handy here.What I'm actually looking for is for a way to force the protocol to be ssh since https prompts people for their password/username. That leads to issues with automation. So a --protocol flag would be handy here.
Sorry for my confusion; if
git_protocolis indeed being respected, how does the--protocolflag help?What I'm actually looking for is for a way to force the protocol to be
sshIf you prefer the
sshprotocol across the board, then you can flip the global config:gh config set git_protocol ssh -h github.comsince
httpsprompts people for their password/username. That leads to issues with automation.You can set up git so that gh is the credential helper, authenticating pulls and pushes to
httpsremotes without the need to interactively supply the password. Run this:git config --global credential.https://github.com.helper '!/path/to/bin/gh auth git-credential'In fact, this is what GitHub CLI (since recently) sets up for you if you go through the
gh auth loginflow and choose "HTTPS" as the preferred protocol.Sorry for my confusion; if git_protocol is indeed being respected, how does the --protocol flag help?
Because the code I'm trying to run is part of an automation. We don't have control over how people have set up their environment. They most likely have an ssh key set up with GitHub and the "gh" cli tool installed.
httpsinvokes a username/password prompt which halts the automation.sshis seamlessly.If you prefer the ssh protocol across the board, then you can flip the global config:
We can't make that part of the automation because people on their devices might now want that to be the default. We just want to invoke the
sshprotocol for this specific command.You can set up git so that gh is the credential helper
That's great, I didn't realise you could do that. But again, we can't control how people have set up their environment. This is however, a good note to make in our installer docs. At least that way we can make the automation seamlessly with
httpsas well.Hope I made my use case clear. If you need any more info feel free to ask! 🙂
Hope I made my use case clear. If you need any more info feel free to ask! 🙂
Sure, thanks for the feedback! Could you open the request for per-invocation
--protocolflag in a separate issue, since we've gone slightly off-topic compared to the original post in this thread? Thank you 🙏Done! #3088. Sorry for hijacking this thread.
ah, when i heard automation i thought of a fully controlled CI environment and not end user machines. thanks for explaining, makes sense!
Reacted by Dries Vints- added a commit that references this issue
on Mar 5, 2021
Describe the feature or problem you’d like to solve
I prefer to clone git repositories by hand, and use
httpsfor opensource projects as that's much faster without SSH authentication going on. As soon as I have something to submit and want to create a fork to push to I use SSH instead of https auth.Setting
git_protocolas suggested by other issues has previously been working fine for this use-case. However, since the introduction of #2434 (to close #1056) settinggit_protocolglobally nor for thegithub.comremote allows this anymore. The change in that PR overwrites the value read fromgit_protocolin the config with the scheme of the forked repo URL.Proposed solution
I propose to change precedence of the protocol used when running
gh repo fork. Right now it is, in order of descending precedence:git_protocolfor the hostgit_protocol.Instead, this should be:
git_protocolfor the hostgit_protocolAlternatively an extra
--protocolflag might work though that makesgit_protocoleven more obsolete for the forking case.Implementation
Upon very quick examination of the configuration stack it seems like that is not currently able to tell whether a retrieved config option is the default or explicitly configured by the user. That complicates the case above as only an explicitly configured
git_protocolshould take precedence over the forked URL scheme.