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>
> * 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
* 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
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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html