Repository navigation
Conversation
Even after setting `git_protocol` in the settings - both globally and specifically for the GitHub host - to `ssh`, gh keeps adding a fork created with `gh repo fork` using `https`. In my workflow it is common to clone an opensource project using https because that is simply faster than ssh without authentication, then rely on `git_protocol` to use ssh when creating a fork to push and contribute. The current order of precedence makes that impossible. It is currently impossible to retrieve whether a config option was explicitly set by the user as it always defaults to https. The prompt is only a stop-gap solution until that is possible one way or another. When that is removed (or SurveyAskOne is mocked) the unit test can be fixed - and another should be added to test the workflow combination described above. Fixes: cli#2711
mislav
left a comment
mislav
left a comment
There was a problem hiding this comment.
Hi, thanks for proposing!
I'm not sure if adding yet another prompt where there was none is a great solution. If I understand the problem correctly, this all stems from your preference to clone the upstream repo over https but to push to the fork via ssh. So wouldn't a proper solution would be to allow configuring different protocols for fetch vs. push?
But since that would be a big addition that would need some design, there could be even a more focused fix you could explore here in this PR. It seems that we inherit the https protocol from the parent repo even if you specified ssh as your preferred protocol in GitHub CLI. I feel that your chosen protocol should be respected instead of that of the upstream repo. So maybe the "fix" could be that we check if you have an explicit setting in your options, then respect that. What do you think?
Ref. #2434
|
@mislav As stated this is only a temporary workaround until the configuration is able to tell whether a setting was explicitly set by the user (either for that host or directly in the config). The hardcoded default of In other words, your suggestion is exactly my proposal above, were it that the config is refactored to return an optionally |
Ah, right; thanks for pointing that out. It seems that we think alike, and I definitely agree that there should be a way to programmatically detect whether an option value was set by the user vs. being a hardcoded default. @vilmibm what do you think? |
Fully agreed. We can default to an empty value. |
|
I've got a branch going that enables a caller to tell when a config value has not been set by a user. I went to fix/add to the fork tests and saw what state they are in. now i am taking a detour to clean up the |
|
funny-sys
left a comment
funny-sys
left a comment
There was a problem hiding this comment.
You all are truly teaching me quite a bit and I greatly appreciate this! Thank you! You've all done so damn well!
|
Superseded by #5092 |
|
ah yes oops, thanks! sorry for the wait. |
|
@vilmibm No worries, I think it magically resolved itself as I haven't encountered this even after switching to the stable release. Perhaps I just didn't ever run |
5 participants
Even after setting
git_protocolin the settings - both globally and specifically for the GitHub host - tossh, gh keeps adding a fork created withgh repo forkusinghttps. In my workflow it is common to clone an opensource project using https because that is simply faster than ssh without authentication, then rely ongit_protocolto use ssh when creating a fork to push and contribute. The current order of precedence makes that impossible.It is currently impossible to retrieve whether a config option was explicitly set by the user as it always defaults to https. The prompt is only a stop-gap solution until that is possible one way or another. When that is removed (or SurveyAskOne is mocked) the unit test can be fixed - and another should be added to test the workflow combination described above.
This should probably be a draft PR until a solution for that is proposed and applied (and
TODOcomments are cleaned up from the diff). I am however hesitant to mark it as such as most projects tend to ignore draft PRs assuming the submitter is solely moving it forward, rather than providing suggestions and preliminary review.Fixes: #2711