Re: Location-agnostic submodules

From: Phil Hord <phil.hord@gmail.com>
Date: May 1, 2012, 15:16 UTC
Message-ID: <CABURp0rUKubfWXxX2ABG2E4dRTEQh4zA0bZFOeXGwv2m4b0YaA@mail.gmail.com>
In-Reply-To: <20120430220244.GL22827@pape.arcanes.fr.eu.org>

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:

Show 9 quoted lines

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

Show 6 quoted lines

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

Show 6 quoted lines

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

Show 5 quoted lines

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