On Saturday 02 December 2006 21:24, Martin Waitz wrote: > On Sat, Dec 02, 2006 at 12:17:44AM +0100, Josef Weidendorfer wrote: > > After some thinking, a submodule namespace even is important for checking > > out only parts of a supermodule, exactly because the root of a submodule > > potentially can change at every commit. > > have you ever thought about the idea that the location may be an > important thing to consider for your decision. Which decision, for what? Sorry, I do not understand. Do you want to say that relative submodule root paths should be kept fix the whole lifetime of a supermodule? Ie. a submodule "identity" is bound to its relative path, and when we move it, it should be seen as deleting at and creating a totally new, different submodule? That's fine. But you have to handle submodule creation/deletion neverless. And while you are at a commit which has a given submodule deleted, you have to keep the submodule data somewhere - referencing it with a name. I do not speak here about the object database, that could be combined; but about all the other files in .git/ of the currently not checked out submodule. > Perhaps the submodule is now used for something else (this is why it was > moved) and that now you'd like to keep it? Can you give a usage szenario? What do you mean here? > Anyway, you can just create several supermodules or implement generic > partial tree support for git. I do not see any reason to special case > submodules here. What should such a general partial tree support look like? I suppose you want to configure paths which should not be checked out. As long as you say that a given submodule always has to exist at a given path, you are right: then, you can say: "Please, do not check out this submodule" which is the same as "Do not check out this path". But I think it is quite restrictive to not allow to move submodules around. When the supermodule upstream decides to move a submodule, your partial tree config to not check out a submodule will be lost. But more important, if you made changes to a given submodule, and pull from upstream which changed the submodule position in-between, your changes will be not taken over to the new position, as the move is seen as creation of a totally independent submodule. Josef - 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