This was an oversight when working on the working tree modifying commands
recursing into submodules.
To test for uninitialized submodules, introduce another submodule
"uninitialized_sub". Adding it via `submodule add` will activate the
submodule in the preparation area (in create_lib_submodule_repo we
setup all the things in submodule_update_repo), but the later tests
will use a new testing repo that clones the preparation repo
in which the new submodule is not initialized.
By adding it to the branch "add_sub1", which is the starting point of
all other branches, we have wide coverage.
Signed-off-by: Stefan Beller <sbeller@xxxxxxxxxx>
---
submodule.c | 3 +++
t/lib-submodule-update.sh | 1 +
2 files changed, 4 insertions(+)
diff --git a/submodule.c b/submodule.c
index 7c3c4b17fb..ccf8932731 100644
--- a/submodule.c
+++ b/submodule.c
@@ -1333,6 +1333,9 @@ int submodule_move_head(const char *path,
struct child_process cp = CHILD_PROCESS_INIT;
const struct submodule *sub;
+ if (!is_submodule_initialized(path))
+ return 0;
+
sub = submodule_from_path(null_sha1, path);
if (!sub)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index fb4f7b014e..22dd9e060c 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@ -73,6 +73,7 @@ create_lib_submodule_repo () {
git checkout -b "add_sub1" &&
git submodule add ../submodule_update_sub1 sub1 &&
+ git submodule add ../submodule_update_sub1 uninitialized_sub &&
git config -f .gitmodules submodule.sub1.ignore all &&
git config submodule.sub1.ignore all &&
git add .gitmodules &&
--
2.12.2.642.g1b8cc69eee.dirty