Or you could create a version of your src folder as a github checkout with submodules for each of the things you want to import.
I struggle to see what the issue is. I knew the first time I wrote an import in Go that this was possible, and that as the libraries for Go are relatively young that it is also likely.
My personal preference is just to keep track of changes fairly regularly and not allow much drift. But that's because up until Go1.1 I was following tip, which meant I was already in that habit.
Though it would be nice if ``go get`` could take a revision or branch/tag name.
I'm a little confused about how this would be an issue in the first place. I mean, surely all the changes are checked into a repository and the working code is on the programmers computer right??? So why doesn't he just share the 'working' code with all of the dependencies if he somehow didn't check in his local copies of the dependencies.
I'm a little suspicious when it is claimed that the original author can't get it to compile. That is just so strange and the simplest explanation was that it was never in a great state anyway.
Yeah... it smells a little odd, goes against the general golang development (when you have a dep, it ends up in src and you check in src... so... yeah).
Or you could create a version of your src folder as a github checkout with submodules for each of the things you want to import.
I struggle to see what the issue is. I knew the first time I wrote an import in Go that this was possible, and that as the libraries for Go are relatively young that it is also likely.
My personal preference is just to keep track of changes fairly regularly and not allow much drift. But that's because up until Go1.1 I was following tip, which meant I was already in that habit.
Though it would be nice if ``go get`` could take a revision or branch/tag name.