Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/go: make git repo special-casing more generic #11458

Closed
josharian opened this issue Jun 29, 2015 · 5 comments
Closed

cmd/go: make git repo special-casing more generic #11458

josharian opened this issue Jun 29, 2015 · 5 comments

Comments

@josharian
Copy link
Contributor

I propose that in addition to the list of well-known domains, go get use the following heuristic to identify cases in which git is the right vcs: Split the domain into components. If any component is exactly "git" or "github", assume it is a git repo. This would cover git.apache.org (#10797) as well as most GitHub Enterprise installations.

10 of the 84 domains at found at godoc.org fit this pattern, so this provides pretty decent coverage.

Thoughts?

/cc @adg @bradfitz

@adg
Copy link
Contributor

adg commented Jun 29, 2015

Would this address enterprise GitHub installations?

On 29 June 2015 at 13:54, Josh Bleecher Snyder notifications@github.com
wrote:

I propose that in addition to the list of well-known domains, go get use
the following heuristic to identify cases in which git is the right vcs:
Split the domain into components. If any component is exactly "git" or
"github", assume it is a git repo. This would cover git.apache.org (#10797
#10797) as well as most GitHub
Enterprise installations.

10 of the 84 domains at found at godoc.org fit this pattern, so this
provides pretty decent coverage.

Thoughts?

/cc @adg https://github.com/adg @bradfitz https://github.com/bradfitz


Reply to this email directly or view it on GitHub
#11458.

@josharian
Copy link
Contributor Author

It would address every GitHub Enterprise installation I've encountered, because basically everyone puts theirs at github.mycompany.com.

@adg
Copy link
Contributor

adg commented Jun 29, 2015

Sounds good to me. Having trouble seeing a downside.

On 29 June 2015 at 14:05, Josh Bleecher Snyder notifications@github.com
wrote:

It would address every GitHub Enterprise installation I've encountered,
because basically everyone puts theirs at github.mycompany.com.


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

@kostya-sh
Copy link
Contributor

@josharian #10797 issue is different though it might be hard to understand from the ticket itself.

Currently (with Go 1.4) Git repos from git.apache.org are correctly cloned using git:// schema.

Go 1.5 treats git:// as insecure and tries to clone using https:// by default. However it doesn't resolve the repo URL properly. For example the correct repo URL for git.apache.org/thrift.git/lib/go/thrift package should be https://git.apache.org/thrift.git while the current code resolves it to https://git.apache.org/thrift/.

https://go-review.googlesource.com/#/c/10092/ fixes this problem.

@ianlancetaylor ianlancetaylor added this to the Unplanned milestone Jul 11, 2015
@rsc
Copy link
Contributor

rsc commented Oct 25, 2017

This doesn't work. In addition to knowing to use git, you also have to know
how to split the path into the repository root URL and the directory within that repo.
For example for github.com/rsc/foo/bar/baz, we know (because it's github)
that the repo is always the first three elements, so github.com/rsc/foo, and the
directory is the rest.

For other git servers it's far from clear that the rule would always be the first
three elements just like github.

It's of course already possible to put a .git into the import path to specify the
split point, at which point no well-known domain is needed.

@rsc rsc closed this as completed Oct 25, 2017
@golang golang locked and limited conversation to collaborators Oct 25, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants