Antecedentes

Usando Git 1.8.1.1 en Linux. El repositorio tiene el siguiente aspecto:

master
  book

El submódulo se creó de la siguiente manera:

$ cd /path/to/master
$ git submodule add https://user@bitbucket.org/user/repo.git book

El booksubmódulo está limpio:

$ cd /path/to/master/book/
$ git status
# On branch master
nothing to commit, working directory clean

Problema

El maestro, por otro lado, muestra que hay "nuevas confirmaciones" para el submódulo del libro:

$ cd /path/to/master/
$ 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:   book (new commits)
#
no changes added to commit (use "git add" and/or "git commit -a")

Git debería ignorar el directorio del submódulo por completo, de modo que el maestro también esté limpio:

$ cd /path/to/master/
$ git status
# On branch master
nothing to commit, working directory clean

Intento fallido # 1 - sucio

Dentro del archivo master/.gitmodulesestá lo siguiente, según esta respuesta :

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = dirty

Intento fallido n. ° 2: sin seguimiento

Cambiado master/.gitmodulesa lo siguiente, según esta respuesta :

[submodule "book"]
        path = book
        url = https://user@bitbucket.org/user/repo.git
        ignore = untracked

Intento fallido n. ° 3 - showUntrackedFiles

Editado master/.git/configa lo siguiente, según esta respuesta :

[status]
   showUntrackedFiles = no

Intento fallido n. ° 4: ignorar

Se agregó el directorio del libro al archivo maestro de ignorar:

$ cd /path/to/master/
$ echo book > .gitignore

Intento fallido n. ° 5: clonar

Se agregó el directorio de libros al maestro de la siguiente manera:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book

Pregunta

¿Cómo puede el booksubmódulo estar en su propio directorio de repositorio bajo el masterrepositorio y hacer que git ignore el booksubmódulo? Es decir, no debería aparecer lo siguiente:

#
#       modified:   book (new commits)
#

¿Cómo suprimir ese mensaje al ejecutar git statusen el repositorio principal?

¿Un artículo sobre las trampas del submódulo git sugiere que este es un uso inapropiado del submódulo?

Para incluir otro repositorio, que no necesita ser rastreado en su super-repositorio, intente esto:

$ cd /path/to/master/
$ rm -rf book
$ git clone https://user@bitbucket.org/user/repo.git book
$ git add book
$ echo "book" >> .gitignore

Entonces comprometerse.

Como se indica en el artículo sobre errores del submódulo de git vinculado :

... el único vínculo entre el padre y el submódulo es [el] valor registrado del SHA extraído del submódulo que se almacena en las confirmaciones del padre.

Eso significa que un submódulo no se guarda mediante su rama o etiqueta extraída, sino siempre mediante una confirmación específica; esa confirmación (SHA) se guarda en el superrepósito (el que contiene el submódulo) como un archivo de texto normal (está marcado como tal referencia, por supuesto).

Cuando verifica una confirmación diferente en el submódulo o realiza una nueva confirmación en él, el superrepósito verá que su SHA extraído ha cambiado. Ahí es cuando obtienes la modified (new commits)línea de git status.

Para eliminar eso, puede:

• git submodule update, que restablecerá el submódulo a la confirmación actualmente guardada en el superrepósito (para obtener más detalles, consulte la página de git submodulemanual ; o
• git add book && git commit para guardar el nuevo SHA en el superrepósito.

Como se menciona en los comentarios, considere abandonar el booksubmódulo: clónelo dentro del superrepósito, si no es necesario rastrear su estado como parte del superrepósito.

Solo corre:

$ 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 puede suprimir (desde git 1.7.2).

El primero es el contenido sin seguimiento que ocurre cuando realiza cambios en su submódulo pero aún no los ha confirmado. El repositorio principal los nota y git status lo informa en consecuencia:

modified: book (untracked content)

Puede suprimirlos con:

[submodule "book"]
    path = modules/media
    url = https://user@bitbucket.org/user/repo.git
    ignore = dirty

Sin embargo, una vez que confirme esos cambios, el repositorio principal volverá a tomar nota y los informará en consecuencia:

modified:   book (new commits)

Si también desea suprimirlos, debe ignorar todos los cambios.

[submodule "book"]
    path = book
    url = https://user@bitbucket.org/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 principal.

En el caso del OP:

git config submodule.<name>.active false

Ver confirmar 1b614c0 , confirmar 1f8d711 , confirmar bb62e0a , confirmar 3e7eaed , confirmar a086f92 (17 de marzo de 2017) y confirmar ee92ab9 , confirmar 25b31f1 , confirmar e7849a9 , confirmar 6dc9f01 , confirmar 5c2bd8b (16 de marzo de 2017) por Brandon Williams ( mbrandonw) .
^{(Combinado por Junio ​​C Hamano - gitster- en el compromiso a93dcb0 , 30 de marzo de 2017)}

submodule: desacoplar el interés de la URL y el submódulo

Actualmente, la submodule.<name>.urlopción de configuración se utiliza para determinar si un submódulo determinado es de interés para el usuario. Esto termina siendo engorroso en un mundo donde queremos tener diferentes submódulos revisados ​​en diferentes árboles de trabajo o un mecanismo más generalizado para seleccionar qué submódulos son de interés.

En un futuro con soporte de árbol de trabajo para submódulos, habrá múltiples árboles de trabajo, cada uno de los cuales puede necesitar solo un subconjunto de submódulos.
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 los grupos de submódulos que les interesan en lugar de ejecutar " git submodule init <path>" en cada submódulo que quieren ver en su árbol de trabajo.

Con este fin se introducen dos opciones de configuración submodule.activey submodule.<name>.active.

• La submodule.activeconfiguración contiene una especificación de ruta que especifica qué submódulos deben existir en el árbol de trabajo.
  • La submodule.<name>.activeconfiguración es una bandera booleana que se usa para indicar si ese submódulo en particular debería existir en el árbol de trabajo.

Es importante tener en cuenta que submodule.activefunciona de manera diferente a las otras opciones de configuración, ya que toma un pathpec.
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 modo que una especificación de ruta, por ejemplo, ' lib/' cubriría todos los módulos tipo biblioteca para permitir que aquellos que estén interesados ​​en módulos tipo biblioteca establezcan " submodule.active = lib/" solo una vez para decir que todos y cada uno de los módulos en ' lib/' son interesante.
2. Una vez que se inventa la característica de atributo de especificación de ruta, los usuarios pueden etiquetar submódulos con atributos para agruparlos, de modo que una especificación de ruta amplia con requisitos de atributo, por ejemplo, ' :(attr:lib)', se pueda usar para decir que todos y cada uno de los módulos con el libatributo ' ' son interesantes.
   Dado que el .gitattributesarchivo, al igual que el .gitmodulesarchivo, es rastreado por el superproyecto, cuando un submódulo se mueve en el árbol del superproyecto, el proyecto puede ajustar en qué ruta ingresa el atributo .gitattributes, al igual que puede ajustar en qué ruta tiene el submódulo .gitmodules.

La respuesta de Nevik Rehnel es ciertamente la correcta para lo que está preguntando: no quería tener un submódulo, ¿cómo diablos salgo de esa situación? .

Solo que, si su masterproyecto requiere el booksubmódulo, es un buen gesto mantenerlo como tal porque de esa manera otros usuarios que revisan su proyecto pueden disfrutar de no tener ningún gitcomando especial para ejecutar (bueno ... hay algunos comandos especiales para usar submódulos, pero creo que aún es más sencillo de administrar).

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

Lo que debe 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 mastera la versión más reciente disponible en el bookrepositorio. Como resultado, este compromiso permite a otros verificar todos los repositorios master& booken la punta.

Entonces, en efecto, terminas con una confirmación más cada vez que realizas cambios en un submódulo. Es semitransparente si también realiza cambios en algunos archivos en el masterrepositorio, ya que confirmaría ambos al mismo tiempo.

correr

git submodule update 

en el nivel de la raíz.