Re: Submodule relative URL problems

[Junio C Hamano <gitster@pobox.com>]

Jonathan Nieder <jrnieder@gmail.com> writes:

>  * More typical usage is to clone from a bare repository (A.git), which
>    wouldn't have this problem.  But I think your case is worth
>    supporting, too.

I think the relative URL among nested submodules was specifically
designed for hosting environments that have forest of bare
repositories to serve as publishing or meeting points.  I personally
do not know where that "worth supporting" comes from, but if the
change can be done without confusing the codepaths involved, I
wouldn't object too much ;-)

>  * Perhaps as a special case when the superproject is foo/.git, git
>    should treat relative submodule paths as relative to foo/ instead
>    of relative to foo/.git/.  I think that would take care of your
>    case without breaking existing normal practices, though after the
>    patch is made it still wouldn't take care of people using old
>    versions of git without that patch.  What do you think?

If we were to start adding special cases, it may also be sensible to
clean up the more normal case of using subdirectories of bare
repositories to represent nestedness (i.e. you can have a submodule
"logs.git", but not "logs").  We could reuse the $GIT_DIR/modules/$sm_name
convention somehow perhaps?

Any change to implement the special case you suggest likely has to
touch the same place as such a change does, as both require some
reorganization of the code that traverses the pathnames to find
related repositories.