cmd/go: get -u fails with git submodules

[gopherbot]

by daniel.fanjul.alcuten:

What does 'go version' print?
go version go1.2.1 linux/amd64
It happens also with go 1.2.

What steps reproduce the problem?
1. Create a git non-bare repository.
2. Create a git submodule on that repository with some go code.
3. Make GOPATH point to that git submodule
4. Run 'go get -u' to update the git submodule

What happened?
It fails with the error:
package <project>: directory "<absolute path of the project>" is
not using a known version control system

What should have happened instead?
It should have detected the git repository of the submodule and successfully updated it.

Please provide any additional information below.

It is probably because the submodule has a .git file that is not a folder:
$ cat $GOPATH/src/<project>/.git
gitdir: <superproject>/.git/modules/<submodule path>

It works after replacing the file .git by a proper fully-fledged folder.

[cznic]

Comment 1:

Ad "Make GOPATH point to that git submodule". GOPATH is a directory path. How it
supposed to point to a file?
The go tool works with packages (in the first approximation) and supports the convention
package == folder. If GOPATH is /foo/bar then package's file with import path "baz/qux"
are sought for in _folder_ /foo/bar/src/baz/qux.
IMO #WontFix

[gopherbot]

Comment 2 by daniel.fanjul.alcuten:

Oh, sorry. I meant a completely different thing:
Make GOPATH point to the proper parent folder.
If the submodule is in:
<superproject>/<path>/src/<project>
With its file:
<superproject>/<path>/src/<project>/.git
Then GOPATH should be or include:
GOPATH=<superproject>/<path>
And the go get command is:
go get -u <project>

[ianlancetaylor]

Comment 3:

Labels changed: added repo-main, release-none.

[gopherbot]

Comment 4:

CL https://golang.org/cl/142180043 mentions this issue.

[gopherbot]

CL https://golang.org/cl/9815 mentions this issue.

[adg]

@tamird sent the above change. Being unsure that fetching git submodules on "go get" is the right thing to do, I asked for some background; they said:

Sure, here are a bunch of repos that would use submodules:
https://github.com/cockroachdb/c-rocksdb
https://github.com/cockroachdb/c-lz4
https://github.com/cockroachdb/c-protobuf
https://github.com/cockroachdb/c-snappy
Currently, each of these repositories maintains a local copy of the upstream underlying native library - we would much rather use a submodule, because it would save us substantial git-noise. Does that sound reasonable?

I'm not sure if this is reasonable or not. @dsymonds @bradfitz @rsc @davecheney thoughts?

[dsymonds]

This feels like a use case that is niche enough (and git submodules are relatively rare) that it is not worth changing go get to support it. The VCS support in go get is already complex enough. I vote for not doing this.

[tamird]

The absence of submodule support makes it impossible to conveniently wrap non go-getable repos to make them go-getable. This is a common need whenever a non-go project is used in a go project (see above).

Also, the added complexity to go get is trivial, it is just replacing a string with a slice and iterating.