`gh repo clone https://github.com/xxx/yyy` should respect `git_protocol` config rather than using the protocol scheme
alexjurkiewicz opened this issue · 4 comments
Describe the bug
When cloning a repository by the Github web UI URL, git_protocol
is not respected.
❯ gh --version
gh version 2.48.0 (2024-04-17)
https://github.com/cli/cli/releases/tag/v2.48.0
❯ gh config set git_protocol ssh
❯ gh repo clone https://github.com/xxx/yyy
Cloning into 'reporting'...
remote: Invalid username or password.
fatal: Authentication failed for 'https://github.com/xxx/yyy.git/'
failed to run git: exit status 128
Expected vs actual behavior
I would expect gh
to respect git_protocol
, which it does when you specify gh repo clone xxx/yyy
Thank you!!
Hey, thanks for the bug report.
If you provide the full URL including protocol then that will override your configured git_protocol
. I've created a PR here that documents this behaviour: #9030, could you have a look and tell me if it makes sense?
Thanks William. IMO, the URL form https://github.com/xxx/yyy
should respect git_protocol
. If you want to explicitly use https protocol, it's possible to use the "real" HTTPS URL, https://github.com/xxx/yyy.git
.
My use case is that I'd like to easily copy and paste URLs from my web browser into my terminal, and have git_protocol
respected.
I hear you. That might be a reasonable approach but unfortunately this has been the behaviour since the command was first introduced and changing it would be backwards incompatible.
The best thing I can suggest is that you use a gh
alias like so:
gh alias set --shell repo-clone 'gh repo clone ${1#https://github.com/}'
This performs a shell parameter expansion to remove https://github.com
. Then you can call:
gh repo-clone https://github.com/xxx/yyy
and it will functionally act as:
gh repo clone xxx/yyy
I've updated the title and labels to better reflect your request and updated the docs in #9030 to make it clear what the current behaviour is.