Forcing to use git (or ssh protocol) when URL ends with .git is problematic when you want https instead

[grecinto]

Does replace example.com/foo/bar vX.Y.Z => private.example.com/foo/bar.git vX.Y.Z not work?

As far as I can tell it does not work with github.com and other "commonly-used VCS hosting sites" (refer to noVSCSuffix in cmd/go/internal/vcs/vcs.go). Go 1.15 gives you "invalid version control suffix in github.com/ path".

@bcmills, if a user could do

replace (
  github.com/foo/bar <version> => github.com/foo/bar.git <version>
)

forcing the use of git instead of https, that could solve it.

How about if you want the opposite behavior? That is, you specified replace .. .git BUT wanted to use HTTPS protocol instead of SSH? Non-github hosting sites like (private) gitlab.com enforces .git extension, but there are cases where developer needs to work on pre-existing code set(e.g. - migrated code to gitlab!) and wanted to retain to use HTTPS but importing in the new gitlab repository, which has .git extension in the url.

Example, this replace will force "go get" or "go mod tidy" to use ssh protocol on fetch, but is there a way to say use HTTPs?

replace (
   github.com/foo/bar <version> => gitlab.com/foo/bar.git <version>
)

Originally posted by @grecinto in #39536

There are cases one wants to use HTTPs even if module URL ends w/ .git. Example, migration of code from GitHub to private GitLab repos. Being able to continue using HTTPs protocol on "go get" or "go mod tidy" (module fetch) will give flexibility to continue using the current code and change it to use git(ssh protocol) at a later point in time, or not at all.

[seankhliao]

go never uses the git protocol, the .git suffix only means to use git as the vcs, git is always invoked with https urls.

[gabyhelp]

Related Issues

• proposal: cmd/go: configurable extra vcs paths #38964
• cmd/go: git VCS qualifier in module path uses git:// scheme #63845 (closed)
• cmd/go: cannot fetch gitlab repo using git:// using insteadOf (macOS git 2.19.1) #28422 (closed)
• cmd/go/internal/get: isSecure does not parse Git repository URIs correctly #23855 (closed)
• proposal: cmd/go: extend syntax go.mod to allow overriding fetch protocol #39536

Related Code Changes

• cmd/go: fix git remote urls
• doc: update "go get" HTTPS answer to mention .netrc
• cmd/go: simplify/fix handling private github repos
• cmd/go: support git.apache.org Git repos

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[grecinto]

go never uses the git protocol, the .git suffix only means to use git as the vcs, git is always invoked with https urls.

Cool, gtk. But can you please give insight on what is happening in my setup?
I migrated code to gitlab in Synology, have this repo available on HTTPs by creating a reverse proxy on HTTPs that relays to plain HTTP in actual gitlab process.

Then when I do go get on this URL, it pauses for very long time then eventually displays "no secured protocol found". Clearly, HTTPs is in play here. My solution also tweaks the URL using the "git config --global url."https://".insteadof" to specify HTTPs protocol.

git clone on this URL(passing credentials on URL & certificate is in git SSL "trusted" cert folder) works fine, it is able to clone using the HTTPs protocol.

And please, don't close it, because I am not sure that it is what it is like how you described. There may be other problems in play here, which then should be fixed.

Why is git clone working using HTTPs protocol? Why is "go get" or "go mod tidy" not able to work if it uses HTTPs? Is there a "discovery" process in these commands that seem not to work? I don't want to go low-level if I don't have to, because at high level, everything is set to use HTTPs, but it is not working.

If "git clone on HTTPs url" is working, why will "go get" and "go mod tidy" not working?

Please respond, on next day, I will file a new issue just to get attention, because I am not sure whether anybody would look into the "closed" issue, but it seems not closed topic yet, coming from my side.

[seankhliao]

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

[grecinto]

Unlike many projects, the Go project does not use GitHub Issues for general discussion or asking questions. GitHub Issues are used for tracking bugs and proposals only.

For questions please refer to https://github.com/golang/go/wiki/Questions

Well, it is subject to debate whether this is an issue or not. Clearly, there is an issue in the "go get" & "go mod tidy" tool because "git clone [HTTPs url on gitlab via reverse proxy]" works. You can't categorize this as a "non-issue" (not yet), it is your opinion. But on my mind, this is an issue. (relativity theory).

The issue will not get fixed if you do this. Which is why perhaps it is still an issue today. I mean, if such is the treatment then most things will just be relegated for Q&A, but no real action will be done.

If we need to change the title of the issue, please recommend a new title, definitely open for that. But not on closing this because there is an issue. It affects a huge set of people/use-case and GitLab is a very famous hosting sln. Imagine not being able to use that in this use-case? It is very "bigly", if you may.

[seankhliao]

it seems quite clear is misconfiguration on your end. please use one of the forums for troubleshooting your setup, the issue tracker is not the appropriate place to do it.

[grecinto]

Ok, 'will go to the forums if (still) needing help in configuration. Your reply also helps us get isolation going, and thus, remove one of the variables at play. Thanks.

[grecinto]

it seems quite clear is misconfiguration on your end. please use one of the forums for troubleshooting your setup, the issue tracker is not the appropriate place to do it.

More info, I found out that the "go get" (or go mod tidy in this respect) is truncating the .git suffix when it tries to communicate to the "HTTPs" remote endpoint as it tries to discover and download the module(s).

Running "go get -x" to print out each step command/URL shows this:

$ go get -x
cd /home/grecinto/go/pkg/mod
git ls-remote https://synology.com/abc/md5-simd
cd /home/grecinto/go/pkg/mod
git ls-remote git+ssh://synology.com/abc/md5-simd

** I am ready to open an issue on this .git suffix being truncated (after next few hrs or tomorrow morning). Because it, the ".git" suffix, should be taken as is.
Here is the problematic line/step where .git suffix was being truncated:

git ls-remote https://synology.com/abc/md5-simd

This should be:

git ls-remote https://synology.com/abc/md5-simd.git

as specified in go.mod, from the "replace statement" like this:

replace (
	github.com/abc/md5-simd v1.1.1 => synology.com/abc/md5-simd.git v1.1.1
)

[Marlinc]

I'm wondering what the solution to this is, we have .git in the URL also because otherwise a big in GitLab gets triggered (https://gitlab.com/gitlab-org/gitlab/-/issues/36354). With .git is able to find the right path.

To pull we use HTTPS with an access token but if I understand this correctly Golang incorrectly interprets the .git at the end as meaning the old Git protocol is being used?