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?