Consider checking in the whole gopath to the VCS, and supply a makefile that calls `GOPATH=$(pwd) go build`.
You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.
Yes, there are silly workarounds. The whole point is that it's a PITA to work with and breaks many common workflows for scant few actual benefits. Especially now that `godep` is in wide use, which just artificially creates the go workspace structure from in-tree dependencies anyway.
That's like saying "I don't use wheels, because I don't live in the prehistoric era when they were invented."
Some tools are fundamental. A tool to solve the problem of executing dependant tasks is one of them.
Solutions to these fundamental problems tend to be implemented early on. Some of those early solutions were poor, and have fallen out of use. Some of them were good, and have been refined in the intervening years, and hence are still with us.
A good tool to solve a fundamental problem is still useful, no matter how old it is.
You see this for Java projects where the whole source code is nested half a dozen folders deep (src/com/foo/bar/baz/myproject/...) so i don't think it's unfamiliar.