Re: [PATCH 2/3] submodule tests: replace cloning from . by "$(pwd)"

[Johannes Sixt <j6t@kdbg.org>]

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