Re: Re: Submodule relative URL problems
- From
Heiko Voigt <hvoigt@hvoigt.net>
- Date
- Jan 13, 2014, 20:31 UTC
- Message-ID
- <20140113203118.GA2606@sandbox-ub>
- In-Reply-To
- <20140113195518.GB18964@google.com>
Hi,
On Mon, Jan 13, 2014 at 11:55:18AM -0800, Jonathan Nieder wrote:
Show 23 quoted lines
> 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