I've been using Go professionally since 0.8 and in production since 1.0; this is correct.
Since day one we have forked every (external) package dependency in production code to our own github account and for all the constant complaining I hear, it has been very little heartache for us.
This has worked great, we periodically update our forks from upstream, once or twice a year need to fixup our code to match, run our unit tests an integration tests, do a little manual testing and call it good.
Vendoring through tarball dumps of GOPATH I can understand, but how do you deal with the dependencies of your dependencies when vendoring through forking?
Of our 40 or so external dependencies (huge project), only a handful themselves have dependencies we needed to also vendor. Its sounds painful, but in practice it hasn't been. We actually stopped using godep, we were getting no reward for the hassle and added complexity.
Unless there is a bug, or new feature we needed, we often just update this stuff when we update the Go release we are using.
My thoughts; KISS until more complexity is actually needed.
Wouldn't that involve changing the references in the mid-level to the leafs? Now you have to maintain changes to all the mid-level packages, sounds like not fun.
Since day one we have forked every (external) package dependency in production code to our own github account and for all the constant complaining I hear, it has been very little heartache for us.
This has worked great, we periodically update our forks from upstream, once or twice a year need to fixup our code to match, run our unit tests an integration tests, do a little manual testing and call it good.