Re: Relative submodule URLs vs. clone URL DWIMming

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