Re: [RFC] Submodules in GIT

From: Josef Weidendorfer <josef.weidendorfer@gmx.de>
Date: Dec 3, 2006, 00:55 UTC
Message-ID: <200612030155.09630.Josef.Weidendorfer@gmx.de>
In-Reply-To: <20061202202428.GT18810@admingilde.org>

On Saturday 02 December 2006 21:24, Martin Waitz wrote:

Show 7 quoted lines

> 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.