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