New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are there any plans to add git submodules support ? #1240

mohanraj-r opened this Issue Oct 4, 2017 · 3 comments


None yet
3 participants
Copy link

mohanraj-r commented Oct 4, 2017

An alternative to use dependency management tools like dep would be to use Git - Submodules to checkout the dependent repos into the vendor directory. There has even been some 3rd party tools that attempted to solve the dependency problem using git submodules.

Given there are some advantages to using git submodules to vendor dependencies, wondering if there has been any discussion or consideration towards supporting git submodules in dep as an option to vendor dependencies ?

@sdboyer sdboyer added the docs label Oct 6, 2017


This comment has been minimized.

Copy link

sdboyer commented Oct 6, 2017

hi, welcome! thanks for the question - this is probably one we should put into the FAQ, it's come up a number of times.

No, git submodules are not going to be a part of dep, beyond the one tiny bit of support we have now (we preserve /vendor/.git, if it exists - cockroachdb uses this technique to keep vendor from bloating their primary repo size). Here's the pro/con list on it:


  • git submodules provide a well-structured way of nesting repositories within repositories.


  • The nesting that git submodules perform is no more powerful or expressive than what dep already does, but dep does it both more generally (for bzr and hg) and more domain-specifically (e.g. elimination of nested vendor directories).
  • Incorporating git submodules in any way would new fork new paths in the logic to handle the submodule cases, meaning nontrivial complexity increases.
  • dep does not currently know or care if the project it operates on is under version control. Relying on submodules would entail that dep start paying attention to that. That it would only be conditionally does not make it better - again, more forking paths in the logic, more complexity.
  • Incorporating submodules in a way that is at all visible to the user (and why else would you do it?) makes dep's workflows both more complicated and less predictable: sometimes submodule-related actions are expected; sometimes submodule-derived workflows are sufficient.
  • Nesting one repository within another implies that changes could, potentially, be made directly in that subrepository. This is directly contrary to dep's foundational principle that vendor is dead code, and directly modifying anything in there is an error.

@sdboyer sdboyer closed this Oct 6, 2017


This comment has been minimized.

Copy link

mohanraj-r commented Oct 8, 2017

Thank you @sdboyer for the detailed pros/cons.
And thanks for adding it to the FAQ 💯


This comment has been minimized.

Copy link

mewmew commented Feb 8, 2018

Thanks, I was also wondering this and the detailed explanation gave me a good ponder. Thanks @sdboyer!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment