[qznc]

He wants to unify submodules and subtrees? Sounds fishy to me, since these are for very completely different use cases.

Submodules are for tying project parts together, where you have control over all of them. For example, the clang compiler frontent could submodule the LLVM backend. Both are under the LLVM project, so people usually work on both of them at the same time. They should not be in the same repo, since LLVM also has other users unrelated to clang.

Subtrees are for integrating external projects, which are not really under your control, but you probably want to follow upstream developments. Since a subtree includes all the repo data, you can cleanly check out, even if the external origin repository vanishes.

[jedbrown]

This is backwards. Subtree import all the data from the sub-project. (There is no way to clone without getting the subtrees because they are a native part of the repository.) You interact with subtree as if you had one project, committing without needing to know that the subtree has its own upstream. You can split out the subtree history and send it upstream. Splitting it out changes the SHA1. You can merge from upstream back into the subtree. Subtree makes the most sense when you have a component that is completely dominated by its parent, but which you want to also release stand-alone.

Submodules provide weaker coupling and make the most sense when the submodule has its own healthy upstream and you want to track those versions. It's awkward if all submodule development is happening from within the parent.

[qznc]

I think we agree about the functionality, but maybe not quite about when what is a appropriate. The subtree/submodule discussion is somewhat similar to merge vs rebase. There is a lot of personal/project-specific opinion in there.

[scribu]

`git subtree` seems like the perfect tool to complement `git submodule`.

Too bad it's not enabled by default: http://engineeredweb.com/blog/how-to-install-git-subtree/

[jedbrown]

Subtree only needs to be installed by the maintainer that interacts with the submodule's upstream. Everyone else just makes normal commits in the parent repo. They don't even need to know that the subtree has its own upstream (but they likely write better commit messages if they know).

[dustingetz]

parent comment is out of date; git subtree is part of git since roughly git 1.8.

[Tobu]

It's part of git/contrib. Depending on the packaging you still need to enable it manually.

[jrochkind1]

I don't think anyone would think external dependencies you have control over are "completely different use cases" from ones you don't have control over, if it weren't for having already adapting to the fact that have to think of them as very different things with git's current toolset.

In fact, many people getting started with git get confused about whether subtree or submodule is appropriate, and end up wanting parts of both.