The go command go get github.com/cloudnativego/gogo-service/service failed first, but then passed on the second run.
Entire sequence of events:
[23:47]$ go get github.com/cloudnativego/gogo-service/service
# cd /Users/../github.com/cloudnativego/gogo-service; git submodule update --init --recursive
No submodule mapping found in .gitmodules for path 'vendor/github.com/cloudfoundry-community/go-cfenv'
package github.com/cloudnativego/gogo-service/service: exit status 1
[23:48]$ go get github.com/cloudnativego/gogo-service/service
[23:49]$ #worked
[23:49]$ ll vendor/github.com/
total 0
drwxr-xr-x 3 _ staff 102 Nov 2 22:48 .
drwxr-xr-x 3 _ staff 102 Nov 2 22:48 ..
drwxr-xr-x 3 _ staff 102 Nov 2 22:48 codegangsta
[23:49]$
Is this a git issue or go get flakiness, or expected behavior?
This is caused by the repository in question using external libraries (in the vendor directory) as submodules, rather than as static vendoring, but not configuring those submodules within the .gitmodules file (which actually appears to be completely absent from that repo). There is a known issue with go get and submodules:
You may be able to file an issue on the repository in question and suggest they move to a static vendoring model (or use govendor's fetch utility or similar with an ignored /vendor/*/ pattern). They aren't the first repo to run into this issue:
Even github itself seems to generally recommend against using submodules anymore:
https://github.com/blog/2104-working-with-submodules
Before you add a repository as a submodule, first check to see if you have a better alternative available. Git submodules work well enough for simple cases, but these days there are often better tools available for managing dependencies than what Git submodules can offer.