Quoting "Junio C Hamano" <gits...@pobox.com>:
Now
the subdirectory repositories are bound as submodules of the top
level directory just fine.


This is indeed possible, but with some serious caveats.

Firstly, if you simply do "git submodule add ./foo" (the obligatory "./" being quite an unobvious pitfall), you get something quite fragile, since now we have submodule.foo.url = ./foo. If the submodules ever get reorganized and foo is moved to ./bar, then it is impossible to check out older versions or alternate branches, since the submodule is no longer where it is expected to be at the origin.

A more robust solution is to use submodule.foo.url = ./.git/modules/foo, since logical name of a module doesn't change. This seems quite kludgy, though, and this cannot be how git-submodule is supposed to be used.

But still, "git submodule update" only looks at the modules in the currently checked-out tree. If we have other branches or old tags that refer to other submodules, there's no simple way to fetch those, too. And there is not even such a concept as a bare repository with modules.

So git-submodule is fundamentally a tool to attach repositories into a tree, not to attach repositories into a repository. That's why it's not really fit for my purposes.

The core problem is that to clone an entire repository and all its submodules, there needs to be a way to list them all remotely. But the git protocol doesn't just allow us to list the subdirectories under .git/modules. Still, there are several ways to do this:

* Just read .gitmodules in every ref and find by brute force every submodule referred to even by a single ref. This doesn't really scale.

* Maintain a list of all the submodules in a repository. This would have to be in a separate metadata branch, and would get rather hairy when we need to merge from a remote that has added other submodules.

* Represent the submodules as refs instead of independent repositories. This is my proposal for subrepositories.

However, I feel that all of these are too drastic changes to make in git-submodule, given that it is already well-established.

The minor problems, like lack of active branch tracking and multiple mount points of a module, could in principle be fixed in git-submodule. But again, I have no fondness for complex shell programming. Perhaps it was justified when the only interface to git's functionality were the command-line tools, but nowadays there are various ways to manipulate git repositories from real programming languages through real libraries (libgit2, dulwich, etc), and I prefer to use those, so I don't really have any motivation to touch git-submodule.


Lauri

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to