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(-)
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html