This is the last topic I intend to finish before preparing the recursive submodule update. The other prerequisites for that next step are Heiko's "allow more sources for config values" and "fetch moved submodules on-demand" topics, which are necessary to populate submodules that were not present in the currently checked out commit and to have all commits of moved or currently not present submodules fetched for later checkout respectively. But these are other threads ... Let's enable users to move submodules (just as easy as they can already remove them with current Git with "git rm") by using a plain "git mv". While using "git submodule update" on a moved submodule cloned by a coworker will still leave the submodule's work tree lying around at the old path, that will be fixed by the recursive submodule update (and is not different from what Git currently does with removed submodules). Replacing a directory containing files tracked by Git or vice versa is still not possible, another issue to be fixed by the recursive submodule update. I tried to CC all parties which showed interest in this topic, hopefully I didn't forget anyone. Jens Lehmann (3): Teach mv to move submodules together with their work trees Teach mv to move submodules using a gitfile Teach mv to update the path entry in .gitmodules for moved submodules builtin/mv.c | 126 ++++++++++++++++++++++++++++++++++------------------------ submodule.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ submodule.h | 3 ++ t/t7001-mv.sh | 94 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 297 insertions(+), 52 deletions(-) -- 1.8.2.377.g1bdb7d0 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html