cli/cli

`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.