From: "Stefan Beller" <sbel...@google.com>
When a submodule is initialized, the config variable
'submodule.<name>.url'
is set depending on the value of the same variable in the .gitmodules
file. When the URL indicates to be relative, then the url is computed
relative to its default remote. The default remote cannot be determined
accurately in all cases, such that it falls back to 'origin'.
The 'origin' remote may not exist, though. In that case we give up looking
for a suitable remote and we'll just assume it to be a local relative
path.
This can be confusing to users as there is a lot of guessing involved,
which is not obvious to the user.
Would a note in the user docs about the fallback you list above also be
useful?
So in the corner case of assuming a local autoritative truth, warn the
user to lessen the confusion.
This behavior was introduced in 4d6893200 (submodule add: allow relative
repository path even when no url is set, 2011-06-06), which shared the
code with submodule-init and then ported to C in 3604242f080a (submodule:
port init from shell to C, 2016-04-15).
In case of submodule-add, this behavior makes sense in some use cases[1],
however for submodule-init there does not seem to be an immediate obvious
use case to fall back to a local submodule. However there might be, so
warn instead of die here.
[1] e.g.
http://stackoverflow.com/questions/8721984/git-ignore-files-for-public-repository-but-not-for-private
"store a secret locally in a submodule, with no intention to publish it"
Reported-by: Shawn Pearce <spea...@spearce.org>
Signed-off-by: Stefan Beller <sbel...@google.com>
---
builtin/submodule--helper.c | 8 +++-----
1 file changed, 3 insertions(+), 5 deletions(-)
--
Philip
