Re: Location-agnostic submodules

[Phil Hord <phil.hord@gmail.com>]

Adding Jens Lehmann, in case he hasn't noticed this thread yet.

On Mon, Apr 30, 2012 at 6:02 PM, Pierre Thierry <pierre@nothos.net> wrote:
> Scribit Phil Hord dies 30/04/2012 hora 16:39:
>> Maybe something like this:
>>     [submodule "foo"]
>>         path = foo-mod
>>         url = ../foo ../foo-alternate
>> https://someplace.com/git/foo.git  https://kernel.org/git/foo
>
> <rant>That is typically the kind of occasion when I wish every config
> file were sexprs...</rant>

Interesting.  But at least it's not yaml.  :-)

>> But if one of them lags behind the others by a day or even an hour,
>> then you may have gitlinks in your superproject which have not made
>> it into the lagging mirror yet.  And this will cause problems.
>
> I see your point, but what if your only repository is lagging behind?
> I.e. in what way is it worse than now?

I actually do not think it is very much worse than now.  But the
specific way it fails in this case is as follows:

Suppose I have mirrors A and B, each containing a superproject and its
submodule.

  A:super:master => A:sub:master
  B:super:master => B:sub:master

A and B are coherent, meaning their superproject gitlinks point to
commits which do exist in the submodule repositories.

Now, I push new commits to A:super and A:sub, giving this:
  A:super:new' => A:sub:new
  B:super:master => B:sub:master

Now, A and B are both internally coherent, but I have a problem if I
try to do this:
  A:super:master' => B:sub:new

This is because the sub:new commit has not made it to B yet, perhaps
intentionally or perhaps because of latency.

This problem still can occur without your change, so I do not think it
is a fatal flaw.  It is just a scenario to consider.

>> Moreover, each time you clone the repository you may get different
>> results.  This would be confusing.
>
> Again, I fail to see the difference with the current state. If the
> commit is specified, you will always get the same results, now or with
> my suggested addition.

The existing implementation has some flaws, and think the multiple
URLs option may expose the flaws further.  Again, not a fatal flaw to
your idea; just something to keep in mind.

Something else to keep in mind:  What you are proposing amounts to a
feature which identifies mirror repositories to use for submodules
when the primary remote repo cannot be reached.  Superprojects have no
such feature.  Why not?

Meanwhile, I really like the other feature you started off with, where
the "embedded" submodule repos could be used as the primary origin.

>> I don't think there is any need for a new 'clone' command since the
>> clone porcelain already understands submodules.
>
> What do you mean? When I clone a repo with submodules, they are not
> cloned as well.

Since git v1.6.5 or so, clone has known the --recursive option.

  git clone --recursive superproject

Since about v1.7.3, fetch and pull also know how to recurse and can do
so by default.

Phil