Johan Herland wrote:
I'd like to fix this, but I'm not sure whether the fix belongs in
builtin-clone.c (i.e. making sure the origin URL is always "correct"
wrt. resolving relative submodule URLs), or in git-submodule.sh (i.e.
adding smarts when resolving relative submodule URLs against the
super-repo's origin URL).
...Johan
I think the right approach is to start with clone and make it record the
real url it is using, regardless of what was input. The problem with
doing this in submodule is that in effect this replicates the search
logic clone would use, and furthermore could lead to nasty surprises by
grabbing the wrong submodule in an extreme case of having two
identically named repositories in different locations on a server.
I was about to create a patch for submodule to always remove trailing
"/.git" before resolving, but in fact a user could put the submodule
.git into the superproject's .git, in a non-bare repository, and then
gitlink that in the checked out submodule. So, it may also be good to
define and enforce rules on how relative url naming can be used for this
purpose. So far, I have only used it for bare repositories using the
"../<path> form keeping the submodules out of the superproject.
Mark
--
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
