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óduloActualmente, 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
ysubmodule.<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:
- 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.- 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 atributolib
''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 degit 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