Re: Submodules implementation

From: Avery Pennarun <apenwarr@gmail.com>
Date: Feb 23, 2010, 23:59 UTC
Message-ID: <32541b131002231559r49fc31e0i4ce46869d27190c8@mail.gmail.com>
In-Reply-To: <k76e57-g67.ln1@burns.bruehl.pontohonk.de>

2010/2/23 Christoph Bartoschek <bartoschek@gmx.de>:

Show 6 quoted lines

> what is the main reason that submodules are their own repositories linked
> into the enclosing one and not just additional pointers in the main
> repository?
>
> My impression is that submodules as pointers to existing tree objects would
> make a design more easier to understand and more user friendly.

The data format itself implements submodules as simply pointers to commits (not trees) located at a particular point in the supermodule. This is very elegant and simple.

Show 5 quoted lines

> Especially I see no need for most of the submodule commands. Maybe "git
> submodule add" but the other commands are already covered by existing ones.
>
> Or is there a tool that uses such additional pointers for submodule
> management?

The implementation of submodule tools, particularly 'git submodule', is the reason that these submodule pointers are implemented as separate repositories. I think the reasons are that a) it seemed expedient at the time, and b) it's one valid way (although not the only way) of thinking about what it means to have one repo point at a commit.

By comparison, my git-subtree tool (http://github.com/apenwarr/git-subtree) is the opposite: its data storage format isn't very elegant (it just has a tree stored inside another tree, as if there were no submodule at all) but its implementation makes it easier for end users (since they don't have to deal with separate repositories).

The ideal tool would be elegant *and* easy to use, but it doesn't exist.

Have fun,

Avery