Jens Lehmann <jens.lehm...@web.de> writes: > Currently using "git mv" on a submodule moves the submodule's work tree in > that of the superproject. But the submodule's path setting in .gitmodules > is left untouched, which is now inconsistent with the work tree and makes > git commands that rely on the proper path -> name mapping (like status and > diff) behave strangely. > > Let "git mv" help here by not only moving the submodule's work tree but > also updating the "submodule.<submodule name>.path" setting from the > .gitmodules file and stage both. This doesn't happen when no .gitmodules > file is found and only issues a warning when it doesn't have a section for > this submodule.
Should it happen when the user has other changes to .gitmodules that hasn't been updated to the index? As this is done in the same final "per-path" loop as adjusting the gitfile links, the worry I expressed in an earlier message about "git mv a/ b/" when "a/x" is a submodule turns out to be unfounded, which is good ;-) -- 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
