Re: Re: Submodule relative URL problems

[Heiko Voigt <hvoigt@hvoigt.net>]

Hi,

On Mon, Jan 13, 2014 at 11:55:18AM -0800, Jonathan Nieder wrote:
> Lianheng Tong wrote:
> 
> > git clone W1:<path to A on W1>/.git  <path to A on W2>
> 
> Interesting.
> 
> Thoughts:
> 
>  * 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.
> 
>  * What would you think of putting symlinks in A's .git directory?
> 
> 	cd A/.git
> 	ln -s ../B ../C ../D .
> 
>  * 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?

I do not fully get the repository layout, since some commands simply do
not work. Nevertheless I think what Lianheng Tong is running into is
the following:

 * If a superproject has *no remote* a relative submodule url is relative
   to the *superproject itself*
 * If a superproject has *a remote* a relative submodule url is relative
   to the *superprojects remote*

The simplest solution is: Have central bare repositories for everything
so that every workstation has the same remote.

The second solution: Make sure both repositories have each other as a
remote. But then you run into a chicken/egg problem when setting the two
up.

The interpretation of relative urls was a design decision back when the
relative urls were introduced. I am quite sure it would produce a lot of
fallout if we change that.

If I get your usecase wrong it would be very helpful if you could
provide us with a working script that creates the repository setup your
are using.

Cheers Heiko