Git: rastrear rama en submódulo pero confirmar en otro submódulo (posiblemente anidado)

Estoy buscando una situación en la que tengo una estructura git con (posiblemente submódulos anidados). Para cada uno de estos submódulos, quiero especificar por separado, si deben rastrear una rama (ver, por ejemplo,Submódulos de Git: especifique una rama / etiqueta)

Por ejemplo, mi proyecto puede verse así:

main.tex
|- submod1 @ master
|    |-subsubmod1 @qsdf123
|- submod2 @ master
|    |-subsubmod2 @shasha12
|- submod3 @ qsdf321

Ahora, quiero una forma de actualizar mis submódulos.

git submodule update --recursive

actualizará todos los submódulos a su último sha grabado (es decir, funcionará para subsubmod1, subsubmod2 y submod3, pero hará cosas incorrectas para el resto. Por otro lado

git submodule update --recursive --remote

actualizará todos los submódulos a la rama asociada (por defecto, master), es decir, funcionará para submod1 y submod2, pero hará cosas incorrectas para el resto.

¿Hay alguna manera de hacer esto bien?

En respuesta a la primera respuesta, aclararé lo que quiero decir con "hacer cosas incorrectas".

Aquí hay un pequeño ejemplo.

bartb@EB-Latitude-E5450 ~/Desktop/test $ git init
Initialized empty Git repository in /home/bartb/Desktop/test/.git/
bartb@EB-Latitude-E5450 ~/Desktop/test $ git submodule add ../remote/ submod1
Cloning into 'submod1'...
done.
bartb@EB-Latitude-E5450 ~/Desktop/test $ git submodule add ../remote/ submod2
Cloning into 'submod2'...
done.
bartb@EB-Latitude-E5450 ~/Desktop/test $ cd submod1
bartb@EB-Latitude-E5450 ~/Desktop/test/submod1 $ git log
commit 42d476962fc4e25c64ff2a807d2bf9b3e2ea31f8
Author: Bart Bogaerts <[email protected]>
Date:   Tue Jun 21 08:56:05 2016 +0300

    init commit

commit db1ba3bc4b02df4677f1197dc137ff36ddfeeb5f
Author: Bart Bogaerts <[email protected]>
Date:   Tue Jun 21 08:55:52 2016 +0300

    init commit
bartb@EB-Latitude-E5450 ~/Desktop/test/submod1 $ git checkout db1ba3bc4b02df4677f1197dc137ff36ddfeeb5f
Note: checking out 'db1ba3bc4b02df4677f1197dc137ff36ddfeeb5f'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at db1ba3b... init commit
bartb@EB-Latitude-E5450 ~/Desktop/test/submod1 $ cd ..
bartb@EB-Latitude-E5450 ~/Desktop/test $ git config -f .gitmodules submodule.submod2.branch master
bartb@EB-Latitude-E5450 ~/Desktop/test $ git commit -a -m "modules"
[master (root-commit) ea9e55f] modules
 3 files changed, 9 insertions(+)
 create mode 100644 .gitmodules
 create mode 160000 submod1
 create mode 160000 submod2
bartb@EB-Latitude-E5450 ~/Desktop/test $ git status
On branch master
nothing to commit, working directory clean
bartb@EB-Latitude-E5450 ~/Desktop/test $  git submodule update --recursive --remote
Submodule path 'submod1': checked out '42d476962fc4e25c64ff2a807d2bf9b3e2ea31f8'
bartb@EB-Latitude-E5450 ~/Desktop/test $ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   submod1 (new commits)

Como puedes ver, después de lo últimogit submodule update --remote submod1 está desprotegido en el maestro, aunque nunca configuré la rama maestra para él. Eso es lo que quiero decir con "hacer cosas mal"

Lo mismo sucede con los submódulos: todos se desprotegen en master en lugar de en su commit específico.

Este "problema" es en realidad el esperado degit submodule update --remote. De la documentación de git:

This option is only valid for the update command. Instead of using the superproject’s recorded SHA-1 to update the submodule, use the status of the submodule’s remote-tracking branch. The remote used is branch’s remote (branch.<name>.remote), defaulting to origin. The remote branch used defaults to master, but the branch name may be overridden by setting the submodule.<name>.branch option in either .gitmodules or .git/config (with .git/config taking precedence).

https://git-scm.com/docs/git-submodule

Especialmente la parte:

The remote branch used defaults to master

Esto es lo que quiero evitar.

Editar: una solicitud adicional es: No quiero hacer ninguna modificación a submods o subsubmods (estos son proyectos conjuntos).

Respuestas a la pregunta(1)

Su respuesta a la pregunta