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