On Fri, Apr 27, 2012 at 10:37 AM, Pierre Thierry <pierre@xxxxxxxxxx> wrote:
> I just discovered the workings of the submodule command, and as I have
> grown to like the fact that a repository is not unique with Git, and
> specifically that it has no unique or central location, I'm bothered
> by how submodule works.
>
> Would there be any major issue in having (1) submodule to be able to
> clone the submodules from the super repository when they are available
> there and (2) having zero, one or many addresses for each submodule,
> used as hints (obviously not used when (1) is satisfied)?
Maybe something like this:
[submodule "foo"]
path = foo-mod
url = ../foo ../foo-alternate
https://someplace.com/git/foo.git https://kernel.org/git/foo
I think the problem now will be that you have an indeterminate source
URL for your submodule. So far as all of your alternate locations are
the same it is probably not a problem. 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.
Moreover, each time you clone the repository you may get different
results. This would be confusing.
But aside from these administrative issues, I think this could work.
> When the repository is not bare, the submodules would be found at
> their place in the tree, nothing difficult here. When the repository
> is bare, there could be a tree with the bare repositories of the
> submodules.
I think this could work even if the repository were bare; these days,
submodule repositories are stored in .git/modules/* anyway. So if it
were possible to craft a bare repository with this structure in place,
then even "bare" repos could support embedded submodules like this.
I think this amplifies the relative URL problem. That problem exists
anyway, but this maybe gives it more ways to fail.
> This could be done by a new subcommand, that would take a remote as an
> optional argument, its default being origin, as usual:
>
> $ git submodule clone origin
>
> As I see it, adding this 'clone' subcommand for the case where the
> repository is not bare couldn't add any compatibility issue, so if I'm
> right on this point, I'd like to try and implement this soon.
I don't think there is any need for a new 'clone' command since the
clone porcelain already understands submodules. Maybe a new switch is
needed to control the remote to use, but this switch is needed for
more cases than just clone.
git remote add shared http://elsewhere.com/project.git
git submodule init --remote=shared foo
This could also solve some existing ambiguities with relative paths
and with 'git-submodule sync', for example.
At first you worried me, but now I am starting to like this idea more and more.
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