Simplemente ejecuta:

$ git submodule update

Esto revertirá el submódulo a la confirmación anterior (especificada en parent-repo), sin actualizar el parent-repo con la última versión del submódulo.

Hay dos tipos de avisos de cambio que puedes suprimir (desde git 1.7.2).

El primero es el contenido sin seguimiento, que ocurre cuando realizas cambios en tu submódulo pero aún no los has confirmado. El repositorio padre nota esto y el estado de git lo informa en consecuencia:

modified: book (untracked content)

Puedes suprimirlos con:

[submodule "book"]
    path = modules/media
    url = https://[email protected]/user/repo.git
    ignore = dirty

Sin embargo, una vez que confirme esos cambios, el repositorio padre una vez más tomará nota e informará de ellos en consecuencia:

modified:   book (new commits)

Si si desea suprimir estos también, debe ignorar todos los cambios

[submodule "book"]
    path = book
    url = https://[email protected]/user/repo.git
    ignore = all

Git 2.13 (Q2 2017) agregará otra forma de incluir un submódulo que no necesita ser rastreado por su repositorio padre.

En el caso de la OP:

git config submodule.<name>.active false

Véase commit 1b614c0, commit 1f8d711, commit bb62e0a, commit 3e7eaed, commit a086f92 (17 Mar 2017), and commit ee92ab9, commit 25b31f1, commit e7849a9, commit 6dc9f01, commit 5c2bd8b (16 Mar 2017) by [45] Brandon Williams (mbrandonw).
^{(Merged by Junio C Hamano -- gitster -- in commit a93dcb0, 30 Mar 2017)}

submodule: desacoplar url e interés de submódulo

Actualmente la opción de configuración submodule.<name>.url se usa para determinar si un submódulo dado es de interés para el usuario. Esto termina siendo incómodo en un mundo donde queremos tener diferentes submódulos comprobado en diferentes worktrees o un mecanismo más generalizado para seleccionar qué submódulos son de interés.

En un futuro con soporte de worktree para submódulos, habrá múltiples árboles de trabajo, cada uno de los cuales solo puede necesitar un subconjunto de los submódulos me fui.
La URL (que es donde se puede obtener el repositorio de submódulos) no debe diferir entre diferentes árboles de trabajo.

También puede ser conveniente para los usuarios especificar más fácilmente grupos de submódulos que les interesan en lugar de correr " git submodule init <path>" en cada submódulo que quieren ver en su trabajo arbol.

Para este fin se introducen dos opciones de configuración, submodule.active y submodule.<name>.active.

• La configuración submodule.active contiene un pathspec que especifica qué submódulos deben existir en el árbol de trabajo.
  • La configuración submodule.<name>.active es una bandera booleana utilizada para indicar si ese submódulo en particular debería existir en el árbol de trabajo.

Es importante tener en cuenta que submodule.active funciones diferente que las otras opciones de configuración ya que toma un pathspec.
Esto permite a los usuarios adoptar al menos dos nuevos flujos de trabajo:

1. Los submódulos se pueden agrupar con un directorio principal, de tal manera que un pathspec por ejemplo 'lib/' cubriría todos los módulos de biblioteca-ish para permitir a aquellos que están interesados en los módulos de biblioteca-ish establecer "submodule.active = lib/" solo una vez para decir que cualquiera y todos los módulos en 'lib/' son interesantes.
2. Una vez inventada la característica pathspec-attribute, los usuarios puede etiquetar submódulos con atributos para agruparlos, de modo que un pathspec amplio con requisitos de atributo, por ejemplo ':(attr:lib)', pueda usarse para decir que todos y cada uno de los módulos con el atributo 'lib' son interesantes.
   Dado que el archivo .gitattributes, al igual que el archivo .gitmodules, es rastreado por el superproyecto, cuando un submódulo se mueve en el árbol de superproyectos, el proyecto puede ajustar qué ruta obtiene el atributo en .gitattributes, al igual que puede ajustar qué ruta tiene el submódulo en .gitmodules.

Nevik Rehnel respuesta es sin duda la correcta para lo que usted está pidiendo: Yo no quería tener un submódulo, ¿cómo diablos salir de esa situación?!.

Solo, si su proyecto master requiere el submódulo book, es un buen gesto mantenerlo como tal porque de esa manera otros usuarios que comprueban su proyecto pueden disfrutar de no tener ningún comando especial git para ejecutar (bien... hay algunos comandos especiales para usar submódulos, pero aún es más fácil de administrar, en general, creo.)

En su caso realiza cambios en el repositorio book y en algún momento confirma esos cambios. Esto significa que tienes nuevas confirmaciones en ese submódulo, que tienen una nueva referencia SHA1.

Lo que necesita hacer en el directorio maestro es confirmar esos cambios en el repositorio maestro.

cd /path/to/master
git commit . -m "Update 'book' in master"

Esto actualizará la referencia SHA1 en master a la versión más reciente disponible en el repositorio book. Como resultado, este commit permite a otros checkout todos los master & book repositorios en la punta.

Así que en efecto terminas con una confirmación más cada vez que haces cambios en un submódulo. Es semitransparente si también realiza cambios en algunos archivos del repositorio master ya que confirmaría ambos al mismo tiempo.

Ejecutar

git submodule update 

En el nivel raíz.