On 10-07-22 03:41 PM, Avery Pennarun wrote: > > 1) Sometimes I want to clone only some subdirs of a project > 2) Sometimes I don't want the entire history because it's too big. > 3) Super huge git repositories start to degrade in performance. The reason we turned to submodules is precisely to deal with repository size. Our code base encompasses the entire FreeBSD tree plus different versions of the Linux kernel, along with various third-party libraries & apps. You don't need everything to build a given product (a FreeBSD product doesn't use any Linux kernels, for example) but because all the products share common code we need to be able to branch and tag the common code along with the uncommon code. So a straight "git clone" that would need to fetch all of FreeBSD plus 4 different Linux kernels and check all that out is a major problem, especially for our automated build system (which could definitely be implemented better, but still). In truth it's the checkout that takes the most time by far, though commands like git-status also take inconveniently long. We chose git-submodule over git-subtree mainly because git-submodule lets us selectively checkout different parts of our code. (AFAIK sparse checkouts aren't yet an option.) We didn't really consider git-subtree because it's not an official part of git, and we didn't want to have to teach (and nag) all our developers to install and maintain it in addition to keeping up with git itself. Besides, git-submodule's collection-of-independent-repos model works fairly well in our situation, though the implementation could definitely be improved (and Jens's list is a really good start). Neither submodule nor subtree really solves our situation, but right now git-submodule is the only thing "official" git offers to manage loosely-coupled code. It would be nice to see git-submodule added to the toolkit, but it would be even nicer if git had better ways to deal with "vast" repositories. Another tool folks should keep in mind in this discussion is 'repo' which Google built for the Android project. Android's code base is also too vast to work well in a single git repository, and I don't think subtrees or submodules would be a good match for them either. M. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html