I'm a moderately experienced Go developer and Git user, but there's something that I can't seem to wrap my head around.
Usually my team uses .gitmodules for package dependencies, and that has been a successful pattern because it points to an exact commit. The entire "vendoring problem" has been solved for us in this way.
However, I recently created a project and used go get to fetch various packages from GitHub instead of using git submodule add. I finished the project, committed everything to my git repo, but when a teammate cloned out the repo, the source code for the dependencies was missing.
Usually I would say "oh, you forgot to run git submodule update --init", but of course they're not submodules. So...I could tell him to run go get -u or something (right?) but that means I'm at the mercy of the dependency's master branch--enter vendoring.
My real question here is: what actually happens when I go get a package and then commit it to my repository? It's not committed into my source tree, and it's not a submodule...I can't tell what the heck it is! What is the precise way that go get and Git are behaving and interacting here?
Bonus round: Why would you want this behavior? Under what circumstances would you want to commit another project into your repo in a way that forces new checkouts to pull the latest version of the source every time?
Basically go get downloads and installs a project. It starts by cloning the repository of the project you want into the GOPATH. So
go get github.com/foo/bar
would be equal to
cd $GOPATH/src/github.com/foo
git clone git@github.com:foo/bar.git
which is a repository of its own.
As of go 1.5 the "vendoring problem" has been solved in a very neat and elegant way and as of go 1.6 it's become the standard way (it was only an experinemt in 1.5). This way you only add the (sub) packages (sometimes single files) you really need, to the structure / repository of your project. There are a few tools out there that take care of vendoring, including godep, from which we currently switched to govendor. It has pretty awesome features. One of which is to update the dependency in your project to a given state (commit, tag, etc) but you can still have the package for other projects, you're working on.
Regarding the bonus question... I'm affraid I'm a bit confused and affraid I don't understand the question in it completely, I'd love to answer it though.