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

Johannes Sixt [off-list ref] writes:

Am 22.10.2016 um 22:46 schrieb Stefan Beller:

quoted

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

quoted

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