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
-- 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
[Newbies FAQ] [Linux Kernel Development] [Free Online Dating] [Gcc Help] [IETF Annouce] [DCCP] [Netdev] [Networking] [Security] [V4L] [Bugtraq] [Free Online Dating] [Photo] [Yosemite] [MIPS Linux] [ARM Linux] [Linux Security] [Linux RAID] [Linux SCSI] [Fedora Users] [Linux Resources]