Can't push in a repo cloned by gh clone

[vendion]

Using the gh clone username/repo syntax to clone a repo I get the following error when trying to push

fatal: remote error: 
  You can't push to git://github.com/username/repo.git
  Use https://github.com/username/repo.git

It looks like the remote URLs are wrong for the git protocol, as seen in git remote show origin

* remote origin
  Fetch URL: git://github.com/username/repo.git
  Push  URL: git://github.com/username/repo.git
  HEAD branch: master
  Remote branches:
    develop tracked
    master  tracked
  Local branch configured for 'git pull':
    master merges with remote master
  Local refs configured for 'git push':
    develop pushes to develop (fast-forwardable)
    master  pushes to master  (up to date)

Shouldn't the URLs be git@github.com:username/repo.git

Here is the output of gh version

gh version
git version 1.9.0
gh version 2.0.0

[tgkokk]

You have to add the -p option while cloning.
On Feb 16, 2014 3:02 AM, "Adam Jimerson" notifications@github.com wrote:

Using the gh clone username/repo syntax to clone a repo I get the
following error when trying to push

fatal: remote error:
You can't push to git://github.com/username/repo.git
Use https://github.com/username/repo.git

It looks like the remote URLs are wrong for the git protocol, as seen in git
remote show origin

• remote origin
  Fetch URL: git://github.com/username/repo.git
  Push URL: git://github.com/username/repo.git
  HEAD branch: master
  Remote branches:
  develop tracked
  master tracked
  Local branch configured for 'git pull':
  master merges with remote master
  Local refs configured for 'git push':
  develop pushes to develop (fast-forwardable)
  master pushes to master (up to date)

Shouldn't the URLs be git@github.com:username/repo.git

Here is the output of gh version

gh version
git version 1.9.0
gh version 2.0.0

Reply to this email directly or view it on GitHubhttps://github.com//issues/195
.

[owenthereal]

@vendion An alternative is to set gh.protocol to https then you could save the -p flag.

This is a compatibility bit inherited from Hub. I personally would like to revisit the decision that was made on why gh.protocol (hub.protocol) is not set to https by default. I mean all URLs could have used the https version without any configuration. This'll save us much trouble of distinguishing public repo URL vs. private repo URL. Besides, GitHub Enterprise only works with https.

/cc @mislav

[tgkokk]

@jingweno One caveat with using https is that GitHub doesn't offer 2FA support over it. GitHub asks for username and password every time I clone/pull a private repository and push to any repository. Of course, inputting my username and password doesn't work. With ssh, I just need my private key.

One way this could be solved is using Application-specific passwords, but even this way git doesn't cache the credentials indefinitely and you can't get the password after one visit to that page.

@mislav Correct me if I'm wrong, but I use hub and I had to change hub.protocol to ssh, so I think that by default it's set to https.

[mislav]

Yep, GitHub doesn't support 2FA over git HTTPS. You have to generate a Personal Access Token to use instead of a password. @tgkokk Caching of credentials in git is a solved problem; see man 7 gitcredentials.

In hub, you used to have to pass -p to hub clone in order for it to clone the repo over ssh protocol. Nowadays, it's automatic if you have push access to the repo. In gh, it seems it's not automatic yet?

[vendion]

I would like to add that if the user is the owner of the repository being
cloned, then gh should grab a URL that would allow pushing as chances are I
would like to make changes and push them back up. I know gh store the
username in ~/.config/gh and using strings.Split to get the
username would work to determine if the user owns that repo or if it should
grab a read only repo.

In my usecase I cloned one of my repos with gh clone and expected it
to use the ssh protocol which would allow me to push changes up, but
instead I got a read-only URL which would be fine if I wanted to clone the
gh repo for example instead of forking and cloning the fork.

As far as caching of credentials goes OAuth is fine, and even preferred,
and as far as 2FA is concerned I was asked for a token when gh was getting
oauth token so I am fine with that.

On Sun, Feb 16, 2014 at 12:24 PM, Mislav Marohnić
notifications@github.comwrote:

Yep, GitHub doesn't support 2FA over git HTTPS. You have to generate a
Personal Access Token to use instead of a password. @tgkokkhttps://github.com/tgkokkCaching of credentials in git is a solved problem; see man
7 gitcredentials.

In hub, you used to have to pass -p to hub clone in order for it to clone
the repo over ssh protocol. Nowadays, it's automatic if you have push
access to the repo. In gh, it seems it's not automatic yet?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/195#issuecomment-35202492
.

[mislav]

As far as caching of credentials goes OAuth is fine, and even preferred, and as far as 2FA is concerned I was asked for a token

This is a different kind of authentication. Both hub and gh will handle GitHub API authentication by asking you for your username/password/2FA code and exchanging that for OAuth token. However, neither hub nor gh will handle git protocol authentication, be that over ssh or https. They assume you already have that part set up.

[vendion]

I'm aware of the difference between the protocols and how they handle
authentication, sorry if that was not clear. I was weighing in on https
discussion about how 2FA was not supported. This issue really is not about
how gh handles authentication, but how gh did not use the ssh URL when
cloning a repo that I own. Which should be the default behavior, unless
the remote host is GHE because that works differently as it would seem.
On Feb 16, 2014 3:58 PM, "Mislav Marohnić" notifications@github.com wrote:

As far as caching of credentials goes OAuth is fine, and even preferred,
and as far as 2FA is concerned I was asked for a token

This is a different kind of authentication. Both hub and gh will handle
GitHub API authentication by asking you for your username/password/2FA
code and exchanging that for OAuth token. However, neither hub nor gh will
handle git protocol authentication, be that over ssh or https. They assume
you already have that part set up.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/195#issuecomment-35212087
.

[mislav]

Yep, that's the user-friendly behavior. hub started doing that in 1.11

[vendion]

Not only user friendly but expected behavior in my opinion. Flags like -p
should be for the exception, which I don't know of a use case, outside of
private and GHE repos, where that would be needed as standard work flow
would be fork then clone that if a user wanted to contribute to a project.
On Feb 16, 2014 4:39 PM, "Mislav Marohnić" notifications@github.com wrote:

Yep, that's the user-friendly behavior. hub started doing that in 1.11mislav/hub@b2fd8df

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/195#issuecomment-35214674
.

[owenthereal]

I somehow missed this cuke. I'll make sure it works. @vendion Thanks for reporting!

[owenthereal]

This is fixed in hub 2.0. Note that moving forward gh will be hub 2.0. I may not port back the fixes to this repo. But I'll make a candidate release for hub 2.0 soon.

[vendion]

Thanks for the heads up about the repo switch. Will this require a full
reinstall or will the selfupdate handle the switch?

On Wed, Oct 15, 2014 at 5:17 PM, Jingwen Owen Ou notifications@github.com
wrote:

This is fixed in hub 2.0
https://github.com/github/hub/blob/gh/features/clone.feature#L128-L138.
Note that moving forward gh will be hub 2.0
mislav/hub#475. I may not port back the fixes
to this repo. But I'll make a candidate release for hub 2.0 soon.

—
Reply to this email directly or view it on GitHub
#195 (comment).

[owenthereal]

@vendion It'll be a full reinstall, since the binary will be hub instead of gh.