Vfrdtyky

Git1.8.5 (October 2013) should simplify the process. Simply do a:

git mv A B

"git mv A B", when moving a submodule A has been taught to relocate its working tree and to adjust the paths in the .gitmodules file.

See more in commit 0656781fadca1:

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. This is because the user might just use plain gitlinks without the .gitmodules file or has already updated the path setting by hand before issuing the "git mv" command (in which case the warning reminds him that mv would have done that for him).

Only when .gitmodules is found and contains merge conflicts the mv command will fail and tell the user to resolve the conflict before trying again.

git 2.9 (June 2016) will improve git mv for submodule:

See commit a127331 (19 Apr 2016) by Stefan Beller (stefanbeller).
^{(Merged by Junio C Hamano -- gitster -- in commit 9cb50a3, 29 Apr 2016)}

mv: allow moving nested submodules

"git mv old new" did not adjust the path for a submodule that lives as a subdirectory inside old/ directory correctly.

submodules however need to update their link to the git directory as
well as updates to the .gitmodules file.

$ mv submodule-oldpath submodule-newpath

$ git rm submodule-oldpath

$ git add submodule-newpath

$ git submodule sync

This solutions doesn’t work for me because when using git add command, the submodule was included into the project as a simple directory and not as a submodule.

the correct solution is:

$ mv submodule-oldpath ~/another-location

$ git rm submodule-oldpath

$ git submodule add submodule-repository-URL submodule-newpath

Source: http://bcachet.github.io/development/2012/05/25/rename-git-submodule/

I just tried a few of the suggested above. I'm running:

$ git --version

git version 1.8.4

I found it was best to de-init the submodule, remove the directory and create a new submodule.

git submodule deinit <submodule name>



git rm <submodule folder name>



git submodule add <address to remote git repo> <new folder name>

At least that is what worked for me best. YMMV!

Edit the .gitmodules file to rename the submodule and then rename the submodule directory.

I think you might need to do a git submodule sync afterwards, but I'm not in a position to check right now.

It's not possible to rename it, so you've to remove it first (deinit) and add it again.

So after removing it:

git submodule deinit <path>

git rm --cached <path>

you may also double check and remove the references to it in:

• .gitmodules


• .git/config


• remove reference folder from .git/modules/<name> (best to make a backup), as each folder has config file where it keeps the reference to its worktree
  

then stage your changes by committing any changes to your repo by:

git commit -am 'Removing submodule.'

and double check if you don't have any outstanding issues by:

git submodule update

git submodule sync

git submodule status

so now you can add the git submodule again:

git submodule add --name <custom_name> git@github.com:foo/bar.git <my/path>

MacOs: When I wanna use VonC solution to change submodule folder Common to lowercase:

git mv Common common

I get

fatal: renaming 'Common' failed: Invalid argument

Solution - use some temporary folder name and move twice:

git mv Common commontemp

git mv commontemp common

That's all :)