Re: Composing git repositories

[Jens Lehmann <Jens.Lehmann@web.de>]

Am 28.03.2013 12:48, schrieb Ramkumar Ramachandra:
> Okay, here's a first draft of the new design.  The new mediator object
> should look like:
> 
>     name = git
>     ref = v1.7.8
> 
> The name is looked up in refs/modules/<branch>, which in turn looks like:
> 
>     [submodule "git"]
>         origin = gh:artagnon/git
>         path = git
>     [submodule "magit"]
>         origin = gh:magit/magit
>         path = git/extensions/magit

What happens when you rename "magit" to "foo" in that branch and want
to check out an older commit of the same branch? That is one of the
reasons why that belongs in to a checked in .gitmodules and not
someplace untracked.

> This solves the two problems that I brought up earlier:
> - Floating submodules (which are _necessary_ if you don't want to
> propagate commits upwards to the root).

If you don't want that either don't use submodules or set the ignore
config so you won't be bothered with any changes to the submodules.
Floating up to the submodule's tip can be easily achieved with a
script (possibly checked in in the superproject). You loose the
reproducibility by doing that, but that's what you asked for. No
problem here.

> - Initializing a nested submodule without having to initialize all the
> submodules in the path leading up to it.

You cannot access a nested sub-submodule without its parent telling
you what submodules it has. Otherwise the first level submodule would
not be self-contained, so you'll need to check it out too to access
the sub-submodules. Nothing to fix here either.

> However, I suspect that we can put more information the mediator
> object to make life easier for the parent repository and make seams
> disappear.  I'm currently thinking about what information git core
> needs to behave smoothly with submodules.

To me your proposal is trying to fix non-issues and breaking stuff
that works, so I see no improvement.