Documented the painful process of moving a remote repository

.gitmodules

@@ -1,9 +1,12 @@
 [submodule "libsodium"]
 	path = libsodium
 	url = git@rho.la:~/libsodium.git
+	branch = rho-fork
 [submodule "mpir"]
 	path = mpir
 	url = git@rho.la:~/mpir.git
+	branch = rho-fork
 [submodule "wxWidgets"]
 	path = wxWidgets
 	url = git@rho.la:~/wxWidgets.git
+	branch = rho-fork

docs/libraries.md

@@ -112,8 +112,51 @@ the submodule has to be in detached head mode, with the head pointing
 directly to a commit, rather than pointing to a branch that points to a
 commit.
 
+You will import a submodule from someone else's project, but eventually you and your team are going to make minor changes to it to customize it to your project.  In which case you will need your own remote team repo, in place of the original other team's repo.
+
+Construct the copied remote repositories so that their default branch is your  tracking branch, not the upstream branch.
+
+``` bash
+git init --bare -b «our_branch»
+```
+
+Then, in your local repository where you created the new branch, reset
+the remote in your local repository to the new remote by editing `.gitconfig`
+and push  «our_branch» from your local in which you created your team's new
+submodule branch to the remote.
+
+or
+``` bash
+git clone --bare «their_remote» -b«their_stable_branch_or_release_tag»
+cd «our_new_remote»
+git symbolic-ref HEAD refs/heads/«our_new_branch»
+```
+
+If you fail to set your remote to your team's default branch, then your
+local repositories will keep getting reset back to their team's branch, and
+chaos ensues. 
+
+
+When moving the remote of a submodule in your local repository (usually from their team's remote to your team's remote) you update `.gitmodules` in your superproject, and in each submodule that has submodules of its own, then
+
+```bash
+git submodule update --init  --recursive --force
+git submodule foreach --recursive 'git status && git switch «our_branch» && git status && git remote -v && git switch --detach'
+```
+
+Your submodule remotes propagate from `.gitmodules` file of your superproject, and their branch propagates from the superproject *and* from the remote default branch.
+
+And the branch will *also* propagate from `.gitmodules` if `branch = ...` is set.
+
+Because git is a distributed archive, it is perfectly possible, and often
+necessary, to work with all these set to different values, *provided* that
+everyone is mindful that they are set to different values, and the
+consequences and implications of them being set to different values.  Which
+consequences and implications get complicated, unobvious, difficult to
+predict, and surprising when you are working with submodules.
+
 Git commands in master project do not look inside the subproject. They
-just look at the subproject's head.
+just look at the subprojects head.
 
 This means that signing off on changes to a submodule is irrelevant.  One
 signs off on the master project, which includes the hash of that submodule

wxWidgets

@@ -1 +1 @@
-Subproject commit 5beff5392a2a760ef38a3a25b51db57c004a32cb
+Subproject commit a8e46b7fdd0c3554bb4a55d729415c91c59d4cba