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