The code to try seeing if a fetch is necessary in a submodule
during a fetch with --recurse-submodules got confused when the path
to the submodule was changed in the range of commits in the
superproject, sometimes showing "(null)". This has been corrected.
* sb/fix-fetching-moved-submodules:
t5526: test recursive submodules when fetching moved submodules
submodule: fix NULL correctness in renamed broken submodules
else {
name = default_name_or_path(p->two->path);
/* make sure name does not collide with existing one */
- submodule = submodule_from_name(the_repository, commit_oid, name);
+ if (name)
+ submodule = submodule_from_name(the_repository,
+ commit_oid, name);
if (submodule) {
warning("Submodule in commit %s at path: "
"'%s' collides with a submodule named "
"the same. Skipping it.",
- oid_to_hex(commit_oid), name);
+ oid_to_hex(commit_oid), p->two->path);
name = NULL;
}
}
git clone . downstream_rename &&
(
cd downstream_rename &&
- git submodule update --init &&
-# NEEDSWORK: we omitted --recursive for the submodule update here since
-# that does not work. See test 7001 for mv "moving nested submodules"
-# for details. Once that is fixed we should add the --recursive option
-# here.
+ git submodule update --init --recursive &&
git checkout -b rename &&
git mv submodule submodule_renamed &&
(