tag remove practices crear best all git status git-submodules ignore

remove - git rename tag



Ignorar nuevos commits para el submódulo git (6)

Fondo

Usando Git 1.8.1.1 en Linux. El repositorio se ve de la siguiente manera:

master book

El submódulo fue creado de la siguiente manera:

$ cd /path/to/master $ git submodule add https://[email protected]/user/repo.git book

El submódulo del book 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 "nuevos commits" 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 debe ignorar por completo el directorio del submódulo, para que el maestro también esté limpio:

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

Intento fallido n. ° 1: sucio

Dentro del archivo master/.gitmodules está el siguiente, según esta respuesta :

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

Intento fallido # 2 - sin seguimiento

Se cambiaron los master/.gitmodules a los siguientes, según esta respuesta :

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

Intento fallido # 3 - showUntrackedFiles

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

[status] showUntrackedFiles = no

Intento fallido n. ° 4: ignorar

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

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

Intento fallido # 5 - clonar

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

$ cd /path/to/master/ $ rm -rf book $ git clone https://[email protected]/user/repo.git book

Pregunta

¿Cómo puede el submódulo del book estar en su propio directorio de repositorio en el repositorio master pero Git ha ignorado el submódulo del book ? Es decir, lo siguiente no debería mostrar:

# # modified: book (new commits) #

¿Cómo suprimir ese mensaje cuando se ejecuta el git status en el repositorio principal?

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


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 del OP:

git config submodule.<name>.active false

Consulte commit 1b614c0 , commit 1f8d711 , commit bb62e0a , commit 3e7eaed , commit a086f92 ( 17/03/2017 ) y commit ee92ab9 , commit 25b31f1 , commit e7849a9 , commit 6dc9f01 , commit 5c2bd8b (16 Mar 2017) por Brandon Williams ( mbrandonw ) .
(Fusionada por 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 del submodule.<name>.url se usa para determinar si un submódulo dado es de interés para el usuario. Esto termina siendo engorroso en un mundo en el que queremos tener diferentes submódulos revisados ​​en diferentes worktrees o un mecanismo más general 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 solo necesitará un subconjunto de los submódulos prestados.
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 que los usuarios especifiquen más fácilmente los grupos de submódulos en los que están interesados, en lugar de ejecutar " git submodule init <path> " en cada submódulo que deseen extraer en su árbol de trabajo.

Para ello, se presentan dos opciones de configuración, submodule.active y submodule.<name>.active .

  • La configuración de submodule.active contiene una ruta de acceso que especifica qué submódulos deberían existir en el árbol de trabajo.
    • El submodule.<name>.active config es un indicador booleano usado para indicar si ese submódulo particular debería existir en el árbol de trabajo.

Es importante tener en cuenta que las funciones de submodule.active son diferentes a las otras opciones de configuración, ya que toma una ruta de acceso.
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 rutaespecífica, por ejemplo, '' lib/ '' abarcaría todos los módulos de biblioteca para permitir que aquellos que estén interesados ​​en los módulos de biblioteca-ish establezcan " submodule.active = lib/ " una sola vez para decir cualquiera y todos los módulos en '' lib/ '' son interesantes.
  2. Una vez que se inventa la característica del atributo pathspec, los usuarios pueden etiquetar los submódulos con atributos para agruparlos, de modo que una ruta de acceso amplia con requisitos de atributos, por ejemplo '' :(attr:lib) '', pueda usarse para decir cualquiera y todos los módulos con el '' El atributo lib ''es interesante.
    Como el .gitattributes archivo .gitattributes , al igual que el archivo .gitmodules , cuando un submódulo se mueve en el árbol del superproyecto, el proyecto puede ajustar qué ruta obtiene el atributo en .gitattributes , al igual que puede ajustar qué ruta tiene el submódulo en .gitmodules .

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

El primero es el contenido sin seguimiento que ocurre cuando haces cambios en tu submódulo pero aún no los has comprometido. El repositorio padre los nota y los informes de estado git en consecuencia:

modified: book (untracked content)

Puede suprimir estos 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 principal volverá a tomar nota e informará en consecuencia:

modified: book (new commits)

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

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


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

Solo que, si su proyecto master requiere el submódulo del book , es un buen gesto mantenerlo así porque de esa manera otros usuarios que realizan el pago de su proyecto pueden disfrutar sin tener ningún comando especial de git (bueno ... hay algunos especiales comandos para usar submódulos, pero aún más simple de administrar, en general, creo.)

En tu caso, realizas cambios en el repositorio de book y en algún momento comprometes 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 principal.

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

Esto actualizará la referencia SHA1 en el master a la versión más nueva disponible en el repositorio de book . Como resultado, este compromiso permite que otros obtengan todos los repositorios de book y master en la punta.

Entonces, en efecto, terminas con un commit más cada vez que realizas cambios en un submódulo. Es semitransparente si también realiza cambios en algunos archivos en el repositorio master ya que se comprometerán ambos al mismo tiempo.


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

$ cd /path/to/master/ $ rm -rf book $ git clone https://[email protected]/user/repo.git book $ git add book $ echo "book" >> .gitignore

Entonces cometer.

Como se indica en el artículo sobre trampas del submódulo git enlazado:

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

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

Cuando revisa una confirmación diferente en el submódulo o hace una nueva confirmación en ella, el super-repositorio verá que su SHA desprotegido ha cambiado. Es entonces cuando obtienes la línea modified (new commits) del git status .

Para eliminar eso, puedes:

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

Como se mencionó en los comentarios, considere abandonar el submódulo del book : clonarlo dentro del superrepo, si el seguimiento de su estado como parte del superrepo no es necesario.


Solo corre:

$ git submodule update

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


correr

git submodule update

en el nivel raíz