How can I manage Go dependencies while checking the vendor directory into version control?

Question

Context

I have written a Go library and would like to lock-in and vendor the third-party dependencies. That way, any backwards-incompatible changes to these third-party dependencies will not break my library for other users. See the original proposal for the Go 1.5 Vendoring Experiment for some additional background on how vendoring works.

I am using Glide to manage dependencies and lock-in specific versions. Since the project is a library intended for other people to use, I would like to check the vendor folder into version control. That way, users of the library do not have install Glide in order to use it. All they have to do is set the environment variable GO15VENDOREXPERIMENT=1.

I have used Glide in the past and I'm very comfortable with it. However, I have never tried to submit the vendor folder to version control before. That's why I am suddenly running into problems. I don't believe this is a problem that Glide needs to fix, otherwise I would open an issue there. Really, this strikes me as a problem with git.

Problem

I'm using git version 2.5.4. When I run glide install, all the dependencies are cloned and stored in the vendor folder. When I try to add the vendor folder to git, it confusingly tries to create submodules for them. (I believe it has to do with the fact that each dependency is a cloned repo and still has a .git file in it). This is not the behavior that I want, and I was surprised that git does this by default. In fact, it took me a while to figure out what was actually happening and why the dependencies weren't being added correctly.

Git submodules are confusing and break a lot of tools. I just want to add the vendored projects to version control as they are. I want all the source code to be there, as is, so it won't mess up any other tools and will work the way I want it to.

Question

Is there a way to turn off this default behavior in git? Ideally it could be on a per-project basis. The only relevant options for .gitconfig I could find appear to do with displaying submodules in git diff or fetching submodules recursively with git fetch, pull, or clone.

If there's not, is there a way to do a one-off add the files and folders in the vendor folder without using submodules? I'm hoping for something like git add --no-submodules vendor but I could not find anything like this.

I realize that I could simply remove the .git file in each dependency, but that solution is not ideal for a number of reasons. Chiefly, I or another contributor could easily forget to remove the .git file and as a result the dependency would not be checked in correctly. We would have to remember to do this anytime we update or add a new dependency.

Answer 1

Note that the original title of this question was "How can I prevent git from using submodules by default?". I have updated the title because the solution I came up with does not involve doing that. As far as I know, there is no way to prevent git from using submodules when the dependencies you add contain a .git directory.

Instead, I've decided to simply let git add the dependencies as submodules. Submodules are admittedly confusing and even come with their own distinct set of commands. What I've discovered is that it doesn't matter. Users of the library will never have to interact with submodules directly because go get and the Go vendor experiment will work fine. Additionally, the glide get and glide install commands will also still work.

So in conclusion, I've decided to stick with submodules, but I don't ever use the submodule commands directly.

You might also be interested in seeing the release notes for version 0.14.1 of Zoom, where I implemented this change and provided some additional context. Glide issue #112 also provides some more information on the problem.

Update: I spoke too soon. It appears that using submodules the way I did (which is just using the default git behavior) causes problems with go get when installing from scratch. I'm deselecting this as the chosen answer until I can figure out how to make it work.