Re: Relative submodule URLs vs. clone URL DWIMming

From: Mark Levedahl <mlevedahl@gmail.com>
Date: Aug 28, 2008, 14:50 UTC
Message-ID: <48B6BB49.3000703@gmail.com>
In-Reply-To: <200808271400.54302.johan@herland.net>

Johan Herland wrote:

Show 11 quoted lines

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