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