From: Johannes Sixt Date: Sun, 23 Oct 2016 10:14:26 GMT Subject: Re: [PATCH 2/3] submodule tests: replace cloning from . by "$(pwd)" Message-ID: <61637cd9-8f83-c988-15c0-54f948153c07@kdbg.org> In-Reply-To: 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'. 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