Hi, On Wed, 1 Apr 2009, Andreas Ericsson wrote: > Johannes Schindelin wrote: > > > On Tue, 31 Mar 2009, P Baker wrote: > > > > > I'll paraphrase to see if I understand your points: > > > > > > *Moving objects from submodule .git directories into the base .git/ > > > directory would protect the submodules and is a good idea. > > > > No, I did not say that. > > > > I said that moving submodules' working directory need to protected when > > renaming/deleting submodules. > > > > Even worse, I think that moving the .git/ directory into the superproject's > > .git/ would be at least quite a bit awkward in the nested case. > > > > Not necessarily. The .git directory of a submodule need not be named .git > inside the superprojects .git directory. I could well imagine something > like this: > > .git/modules/submod(.git)/modules/nested-submod(.git) > > For deeply nested submodules (eurgh), one might run into path length limit > issues though. The point is that we will need some library-like function > to find the repository of the submodule. Once that's done, the same call > with a different $gitdir should be able to find the nested submodule. It appears to me as a solution in need of a problem. > I'm also thinking of libgit2 here, where each repository will be > represented as a struct that must be passed to the various $gitdir > searching functions. This is necessary to allow a single program to > access multiple repositories, and the .git/modules scheme makes > supporting submodules in the library quite trivial. First: libgit2 is not an issue for this thread AFAIAC. Second: accessing submodules' repositories is quite trivial at the moment. So much so that git-submodule can still get away with being a shell script. Ciao, Dscho -- 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
