Re: Location-agnostic submodules

["Philip Oakley" <philipoakley@xxxxxxx>]

From: "Phil Hord" <phil.hord@xxxxxxxxx> 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@xxxxxxxxxx> 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 

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