From: Philip Oakley <philipoakley@iee.org>
Date: Tue, 01 May 2012 17:19:38 GMT
Subject: Re: Location-agnostic submodules
Message-ID: <732A8D2DB3374CD6BC12A5E7C4384313@PhilipOakley>
In-Reply-To: <CABURp0rUKubfWXxX2ABG2E4dRTEQh4zA0bZFOeXGwv2m4b0YaA@mail.gmail.com>

From: "Phil Hord" <phil.hord@gmail.com> Sent: Tuesday, May 01, 2012 4:16 PM
> 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.

Would an alternative be something like:
    git submodule update <module> --from <remote>

so that the user can state which of the current submodule's remotes should 
be used for fetching the desired update.

For compatibility, the update may need to use the '--reference' or something 
similar, or perhaps a different command word
    `git submodule fetch <module> --from <remote>`

I was just stung on msysgit (submodule `git`) because its NetInstall clones 
from the main repos, but I had forked my own copies, so the submodule URLs 
weren't right for me (doh). Luckily I have a patch of my silenty overwritten 
changes...

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

Philip