cmd/go: go get git@github.com instead of https://

[lukescott]

What steps will reproduce the problem?

1. go get github.com/user/package
2. cat $GOPATH/src/github.com/user/package/.git/config

What is the expected output?

[remote "origin"]
        url = git@github.com:user/package.git

What do you see instead?

[remote "origin"]
        url = https://github.com/user/package

Please provide any additional information below.

When using go get a GitHub repo's remote points to the https endpoint instead of the SSH
endpoint. The result is having to enter your username and password for private repos.
This can be problematic when you have multiple private repos to pull from.

There should be an option for that if a repo is private git@ should be used instead of
https://. That way the configured SSH certificate can be used instead.

[minux]

Comment 1:

you can add the following two lines to ~/.gitconfig to work around this problem:
[url "git@github.com:"]
    insteadOf = https://github.com/

[minux]

Comment 1:

you can add the following two lines to ~/.gitconfig to work around this problem:
[url "git@github.com:"]
    insteadOf = https://github.com/

[lukescott]

Comment 2:

Yeah I have that, but for some reason it isn't working for another developer working on
the same project. To avoid problems in the future I was hoping that the go get tool
could be a little more intelligent in this regard.

[lukescott]

Comment 2:

Yeah I have that, but for some reason it isn't working for another developer working on
the same project. To avoid problems in the future I was hoping that the go get tool
could be a little more intelligent in this regard.

[garyburd]

Comment 3:

There's an app for fixing the remote: https://github.com/nf/remotefix/blob/master/main.go

[garyburd]

Comment 3:

There's an app for fixing the remote: https://github.com/nf/remotefix/blob/master/main.go

[adg]

Comment 4:

Luke: how can we achieve this?
Github doesn't provide any distinction between public and private repos, except that you
can't see the private ones without logging in.

[adg]

Comment 4:

Luke: how can we achieve this?
Github doesn't provide any distinction between public and private repos, except that you
can't see the private ones without logging in.

[lukescott]

Comment 5:

You could do a HEAD request of the URL. If it comes back as 200 OK it's public, and if
it's 404 it's private. When trying to `go get` a non-existent repo it creates the
directory anyway.
Github also has an REST API that could be used:
http://developer.github.com/v3/repos/#get
Another option is to just have an environmental variable that toggles the behavior of go
get for all github.com repos, regardless if they're public or private. Downside of that
is having to enter your private key password for public repos, but you only have to do
that once every so often.

[lukescott]

Comment 5:

You could do a HEAD request of the URL. If it comes back as 200 OK it's public, and if
it's 404 it's private. When trying to `go get` a non-existent repo it creates the
directory anyway.
Github also has an REST API that could be used:
http://developer.github.com/v3/repos/#get
Another option is to just have an environmental variable that toggles the behavior of go
get for all github.com repos, regardless if they're public or private. Downside of that
is having to enter your private key password for public repos, but you only have to do
that once every so often.

[rsc]

Comment 6:

Hmm, private or doesn't exist.
I still think cmd/go is doing the right thing here. It is making tradeoffs in favor of
users of packages, not developers. Developers can run 'git clone' to get started.

Status changed to WorkingAsIntended.

[rsc]

Comment 6:

Hmm, private or doesn't exist.
I still think cmd/go is doing the right thing here. It is making tradeoffs in favor of
users of packages, not developers. Developers can run 'git clone' to get started.

Status changed to WorkingAsIntended.

[lukescott]

Comment 7:

Isn't cmd/go a developer tool? 'git clone' doesn't download dependencies. What about
adding an -ssh flag? 'go get -ssh github.com/user/package' would use ssh for the named
package and any new dependencies.

[lukescott]

Comment 7:

Isn't cmd/go a developer tool? 'git clone' doesn't download dependencies. What about
adding an -ssh flag? 'go get -ssh github.com/user/package' would use ssh for the named
package and any new dependencies.

[gopherbot]

Comment 8 by sam@ward.io:

I have to agree that an -ssh flag sounds great, since  'git clone' doesn't entirely
replace 'go get'.

[gopherbot]

Comment 8 by sam@ward.io:

I have to agree that an -ssh flag sounds great, since  'git clone' doesn't entirely
replace 'go get'.

[gopherbot]

Comment 9 by Justin.Ruggles:

I agree that this is really awkward. This situation also applies to Github Enterprise
repositories. Having to add a .gitconfig in order to script 'go get' for an automated
build is cumbersome.

[gopherbot]

Comment 9 by Justin.Ruggles:

I agree that this is really awkward. This situation also applies to Github Enterprise
repositories. Having to add a .gitconfig in order to script 'go get' for an automated
build is cumbersome.

[kodabb]

I would like to reopen this bug after the transfer from https://code.google.com/p/go/issues/detail?id=6968

I believe that the comments have not been fully addressed, and although appreciating the developers' work, the "it's not a bug, it's a feature" answer does not fully resolve the issue at hand.

This is a serious limitation of the usefulness of 'go get' especially when non-devs need to update go dependencies and when devs need to use enterprise github.

[kodabb]

I would like to reopen this bug after the transfer from https://code.google.com/p/go/issues/detail?id=6968

I believe that the comments have not been fully addressed, and although appreciating the developers' work, the "it's not a bug, it's a feature" answer does not fully resolve the issue at hand.

This is a serious limitation of the usefulness of 'go get' especially when non-devs need to update go dependencies and when devs need to use enterprise github.

[ianlancetaylor]

This should perhaps be discussed on golang-dev.

[ianlancetaylor]

This should perhaps be discussed on golang-dev.

[gabriel]

Having trouble finding this discussion on golang-dev. Does anyone have a link to the thread?

[gabriel]

Having trouble finding this discussion on golang-dev. Does anyone have a link to the thread?

[james-lawrence]

Agree that 'working as intended' is not really an answer.

[james-lawrence]

Agree that 'working as intended' is not really an answer.

[bmhatfield]

+1 to doing something better here. I don't think "WorkingAsIntended" is fair.

[bmhatfield]

+1 to doing something better here. I don't think "WorkingAsIntended" is fair.

[gabriel]

Is there a reason it wants to assume https:// and not allow git@github.com... This makes it hard to use private or writable repos (you can't use ssh keys) and are forced to (http) authenticate on every access.

If there were an option to override this error/setting for go get ... maybe go get --allow-ssh?

Is anyone on the go team using private repos? Seems like a very common use case that a lot of people are struggling with.

[gabriel]

Is there a reason it wants to assume https:// and not allow git@github.com... This makes it hard to use private or writable repos (you can't use ssh keys) and are forced to (http) authenticate on every access.

If there were an option to override this error/setting for go get ... maybe go get --allow-ssh?

Is anyone on the go team using private repos? Seems like a very common use case that a lot of people are struggling with.

[gonzaloserrano]

Closed? :_(

[gonzaloserrano]

Closed? :_(

[mdempsky]

cmd/go uses https:// by default because that's what github recommends: https://help.github.com/articles/which-remote-url-should-i-use/

To avoid needing to reauthenticate for every access, you can setup a Git credential helper: https://help.github.com/articles/caching-your-github-password-in-git/

If you need/want to use git@github.com instead of https://, then see Minux's initial response on the issue: #6968 (comment)

[mdempsky]

cmd/go uses https:// by default because that's what github recommends: https://help.github.com/articles/which-remote-url-should-i-use/

To avoid needing to reauthenticate for every access, you can setup a Git credential helper: https://help.github.com/articles/caching-your-github-password-in-git/

If you need/want to use git@github.com instead of https://, then see Minux's initial response on the issue: #6968 (comment)

[gabriel]

Oh awesome, thanks for pointing to the git credential helper, that works.

BTW, if you do minux's suggestion you still get an error. It might have
worked in the past but not anymore?

On Mon, Apr 13, 2015 at 12:26 PM, Matthew Dempsky notifications@github.com
wrote:

cmd/go uses https:// by default because that's what github recommends:
https://help.github.com/articles/which-remote-url-should-i-use/

To avoid needing to reauthenticate for every access, you can setup a Git
credential helper:
https://help.github.com/articles/caching-your-github-password-in-git/

If you need/want to use git@github.com instead of https://, then see
Minux's initial response on the issue: #6968 (comment)
#6968 (comment)

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

[gabriel]

Oh awesome, thanks for pointing to the git credential helper, that works.

BTW, if you do minux's suggestion you still get an error. It might have
worked in the past but not anymore?

On Mon, Apr 13, 2015 at 12:26 PM, Matthew Dempsky notifications@github.com
wrote:

cmd/go uses https:// by default because that's what github recommends:
https://help.github.com/articles/which-remote-url-should-i-use/

To avoid needing to reauthenticate for every access, you can setup a Git
credential helper:
https://help.github.com/articles/caching-your-github-password-in-git/

If you need/want to use git@github.com instead of https://, then see
Minux's initial response on the issue: #6968 (comment)
#6968 (comment)

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

[mdempsky]

I don't think so. I just verified, and Minux's suggestion works fine for me with Git 2.2 on Ubuntu 14.04. I also regularly use similar insteadOf configs to work with Go code in private (non-GitHub) Git repos.

You can also try running:

git config --global url.git@github.com:.insteadOf https://github.com/

instead of manually editing your .gitconfig file. If that still doesn't work for you, I suggest following up with the Git developers.

[mdempsky]

I don't think so. I just verified, and Minux's suggestion works fine for me with Git 2.2 on Ubuntu 14.04. I also regularly use similar insteadOf configs to work with Go code in private (non-GitHub) Git repos.

You can also try running:

git config --global url.git@github.com:.insteadOf https://github.com/

instead of manually editing your .gitconfig file. If that still doesn't work for you, I suggest following up with the Git developers.

[gonzaloserrano]

Hi,

I ended up doing this, which is to use SSH for my company's repositories.

[url "git@github.com:mycompanyname"]
    insteadOf = https://github.com/mycompanyname

Thanks guys.

[gonzaloserrano]

Hi,

I ended up doing this, which is to use SSH for my company's repositories.

[url "git@github.com:mycompanyname"]
    insteadOf = https://github.com/mycompanyname

Thanks guys.

[kodabb]

Although the workaround exists, I think I and a lot of people here would appreciate to have it supported officially. Also adding a flag to a command is simpler than editing a gitconfig file in various deployment scenarios.

[kodabb]

Although the workaround exists, I think I and a lot of people here would appreciate to have it supported officially. Also adding a flag to a command is simpler than editing a gitconfig file in various deployment scenarios.

[bradfitz]

Also adding a flag to a command is simpler

Adding a flag increases complexity, documentation requirements, and mental overhead trying to read the docs. We try really hard to avoid flags, options, and complexity.

than editing a gitconfig file in various deployment scenarios.

You should not be using go get in deployment.

[bradfitz]

Also adding a flag to a command is simpler

Adding a flag increases complexity, documentation requirements, and mental overhead trying to read the docs. We try really hard to avoid flags, options, and complexity.

than editing a gitconfig file in various deployment scenarios.

You should not be using go get in deployment.

[gonzaloserrano]

You should not be using go get in deployment.

What would you use in that case? Just wondering :)

[gonzaloserrano]

You should not be using go get in deployment.

What would you use in that case? Just wondering :)

[bradfitz]

Let's move discussion to golang-nuts@. This isn't for a bug tracker.

[bradfitz]

Let's move discussion to golang-nuts@. This isn't for a bug tracker.

[anacrolix]

Can you provide links to the discussions on golang-nuts or golang-dev?

[anacrolix]

Can you provide links to the discussions on golang-nuts or golang-dev?

[adg]

@anacrolix https://groups.google.com/forum/#!topic/golang-nuts/Zi-Kw2tbif8

That's one.

[adg]

@anacrolix https://groups.google.com/forum/#!topic/golang-nuts/Zi-Kw2tbif8

That's one.