(Changed subject)
(+CC: Peff; I suspect he'll be interested in the repository
composition discussion)

Jens Lehmann wrote:
> Am 25.03.2013 20:57, schrieb Ramkumar Ramachandra:
>> Okay, I'll do it step-by-step now, with a live example:
>> [...]
>>  What is going on, seriously?
> Pilot error, mostly omitting the --recursive option and some
> - fixable - usability issues. Patches welcome.

As a user inexperienced with recursive submodules (I've only used them
in this repository), I found it highly confusing.  Thanks for clearing
them up.

It was highly exaggerated and dramatized to make the following points clear:

1. With the current limitation of cd-to-toplevel, it's extremely
unpleasant to work with many levels of nesting.

2. I thought no operation could be performed without cd-to-toplevel,
as even 'git submodule foo' complains about this (instead of saying
"command not found").  Having to go to each submodule subdirectory to
perform operations is just horrible.

3. To change a submodule, I'll have to propagate the change upwards,
creating new commits in each of the outer submodules, and the

Apart from the implementation glitches, I don't like the design;
submodules don't compose well:

1. There's an inherent asymmetry between the superproject and each of
the subprojects, because the superproject owns all the object stores.
Why is it absolutely necessary to relocate the object stores?

2. The metadata is tracked as a file (.gitmodules) in the git
repository.  While it makes it possible for different branches to have
different submodules, it's impossible to say 'git submodule sync
a/b/c/d' (see: 'repo sync'), where b, c haven't been initialized.

3. The current implementation only allows me to compose with commit
objects, but what if I want to compose with refs?  ie. What if I want
to track the tip of the 'master' of a submodule in a superproject?  I
don't want to commit-cascade everytime I make a minor change in a
deeply nested submodule.

Other solutions such as repo (see: depot_tools) solve different
problems but are huge failures when it comes to composability; repo
uses a central manifest repository, for example.  Is it impossible to
build a tool that can truly compose git repositories?  I think
submodules gets a lot of things Right, and we'd have to start from

>> This is just two levels of nesting: with more levels of nesting,
>> things only get worse.
> Yes, you cannot have the cake and eat it. Either you incorporate
> everything into a single repo (e.g. using subtree) and loose the
> strong distinction which content belongs to which upstream repo
> (which AFAIK is a valid choice unless you want to contribute back
> to the submodule's upstream) or you'll have to cope with the
> submodule borders showing up from time to time, reminding you
> which part of the work tree has another upstream.

I don't think it's impossible.  We just haven't thought hard enough
about composition.
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