Adding a submodule with a relative repository path did only succeed when
the superproject's default remote was set. But when that is unset, the
superproject is its own authoritative upstream, so lets use its working
directory as upstream instead.
This allows users to set up a new superpoject where the submodules urls
are configured relative to the superproject's upstream while its default
remote can be configured later.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
or ../), the location relative to the superproject's origin
-repository.
+repository. If the superproject doesn't have an origin configured
+the superproject is its own authoritative upstream and the current
+working directory is used instead.
+
<path> is the relative location for the cloned submodule to
exist in the superproject. If <path> does not exist, then the
{
remote=$(get_default_remote)
remoteurl=$(git config "remote.$remote.url") ||
- die "remote ($remote) does not have a url defined in .git/config"
+ remoteurl=$(pwd) # the repository is its own authoritative upstream
url="$1"
remoteurl=${remoteurl%/}
sep=/
)
'
-test_expect_success 'add should fail when path is relative but no url is set in the superproject' '
+test_expect_success 'use superproject as upstream when path is relative and no url is set there' '
(
cd addtest &&
- test_must_fail git submodule add ../repo relative
+ git submodule add ../repo relative &&
+ test "$(git config -f .gitmodules submodule.relative.url)" = ../repo &&
+ git submodule sync relative &&
+ test "$(git config submodule.relative.url)" = "$submodurl/repo"
)
'