Johannes Sixt <j6t@xxxxxxxx> writes: > Am 22.10.2016 um 22:46 schrieb Stefan Beller: >> I have looked into it again, and by now I think the bug is a feature, >> actually. >> >> Consider this: >> >> git clone . super >> git -C super submodule add ../submodule >> # we thought the previous line is buggy >> git clone super super-clone > > At this point, we *should* have this if there were no bugs (at least > that is my assumption): > > /tmp > ! > + submodule <- submodule's remote repo > ! > + foo <- we are here (.), super's remote repo > ! > + super <- remote.origin.url=/tmp/foo/. > ! > + submodule <- remote.origin.url=/tmp/foo/./../submodule > submodule.submodule.url=../submodule > > When I test this, 'git submodule add' fails: > > foo@master> git -C super submodule add ../submodule > fatal: repository '/tmp/foo/submodule' does not exist > fatal: clone of '/tmp/foo/submodule' into submodule path > '/tmp/foo/super/submodule' failed > >> Now in the super-clone the ../submodule is the correct >> relative url, because the url where we cloned from doesn't >> end in /. > > I do not understand why this would be relevant. The question is not > how the submodule's remote URL ends, but how the submodule's remote > URL is constructed from the super-project's URL and the relative path > specified for 'git submodule add'. FWIW, that matches my understanding. > Whether ../submodule or ./submodule is the correct relative URL > depends on where the origin of the submodule is located relative to > the origin of the super-project. In the above example, it is > ../submodule. However, the error message tells us that git looked in > /tmp/foo/submodule, which looks like the /. bug! > > I do not understand where you see a feature here. What am I missing? > > -- Hannes