Why doesn't url.<base>.insteadOf work with `go get` anymore?


(David E Wheeler) #1

I have a Go project in a Git repository on a BitBucket host used for internal development. We use Git remote URLs that start with ssh://git@source.example.com:7999/, but BitBucket always tells Go that the URLs start with https://source.example.com/scm/. So I have this in my ~/.gitconfig:

[url "ssh://git@source.example.com:7999/"]
	insteadOf = https://source.example.com/scm/

That configuration used to do the trick, but at some point ceased to work. Have a look:

$ go get -v -d -t -u ./...
Fetching https://source.example.com/iol/thingy?go-get=1
Parsing meta tags from https://source.example.com/iol/thingy?go-get=1 (status code 200)
get "source.example.com/iol/thingy": found meta tag get.metaImport{Prefix:"source.example.com/iol/thingy", VCS:"git", RepoRoot:"https://source.example.com/scm/iol/thingy.git"} at https://source.example.com/iol/thingy?go-get=1
package source.example.com/iol/thingy: source.example.com/iol/thingy is a custom import path for https://source.example.com/scm/iol/thingy.git, but /Users/david/dev/go/src/source.example.com/iol/thingy is checked out from ssh://git@source.example.com:7999/iol/thingy.git

I have very carefully compared the strings and they all appear to be correct. What am I missing?

Thanks,

David


(Constantin Konstantinidis) #2

It is not clear if your repo is private or not and which version of Go you’re using.
The format is go get {hostname}/{project_key}/{repo_slug}
It remains a problem in some cases according to issue https://github.com/golang/go/issues/26232


(David E Wheeler) #3

I was using Go 1.10, but just upgraded to 1.11.1 and see the same issue.

The repository is private, yes, but by replacing the https URL with the ssh URL, it should transparently use my SSH keys loaded into SSH Agent. This feels to me like Git fails to substitute the URL, but I can’t see what URL Git resolves to.

But maybe I can? This seems to work:

git ls-remote -q  https://source.example.com/scm/iol/thingy.git
33a5a7f71387172ea37cb45edee948e0ce33f3bf	HEAD
cd27380a4fc3f3aff64b9910bd3e14a5c0c3be07	refs/heads/develop
33a5a7f71387172ea37cb45edee948e0ce33f3bf	refs/heads/master
22dc734031e04ccf01a95e366451eb65522b84a5	refs/tags/v0.2.0
a3a0c4eb87b1d0f28839d4b93f51e11602459b8b	refs/tags/v0.2.0^{}

So it seems like Git resolves is properly. If I change the URL in ~/.gitconfig this command returns an error, so I know that the git client, at least, properly changes the URL. Maybe I also need to change the remote URLs for these clones?


(David E Wheeler) #4

Ah, yes indeed, this fixes the issue:

git remote set-url origin https://source.example.com/scm/iol/thingy.git

Okay I get it. Wish I’d thought of it months ago! I using the -f option is more-or-less equivalent: the pulls work, it just ignores that the remote is different than the import. And I guess that’s necessary because go get doesn’t know to read ~/.gitconfig.


(Constantin Konstantinidis) #5

Thanks for the details. Could you confirm your git version ?


(David E Wheeler) #6
$ git version
git version 2.17.1