una - Explica qué regla de gitignore está ignorando mi archivo

ignorar carpetas en git

Question

¿Hay alguna manera de ver por qué git ignora algunos archivos (es decir, qué regla en un archivo .gitignore está haciendo que el archivo sea ignorado)?

Imagina que tengo esto (o un escenario mucho más complejo, con cientos de carpetas y decenas de archivos .gitignore :

/
-.gitignore
-folder/
    -.gitignore
    -subfolder/
              -.gitignore
              -file.txt

Si ejecuto git add folder/subfolder/file.txt git puede quejarse de que se haya ignorado:

The following paths are ignored by one of your .gitignore files:
folder/subfolder/file.txt
Use -f if you really want to add them.

¿Hay alguna forma de saber cuál de todos los posibles .gitignore tiene una regla para ignorar este archivo y también mostrar la regla? Me gusta:

The following paths are ignored by your folder/.gitignore file (line 12: *.txt)
folder/subfolder/file.txt
Use -f if you really want to add them.

O solo:

$ git why-is-ignored folder/subfolder/file.txt
folder/.gitignore:12:*.txt

Answer 1

Actualización git 2.8 (marzo 2016):

GIT_TRACE_EXCLUDE=1 git status

Consulte " Una forma de validar el archivo .gitignore "

Eso es complementario al git check-ignore -v describe a continuación.

Respuesta original: septiembre de 2013 (git 1.8.2, luego 1.8.5+):

git check-ignore mejora de nuevo en git 1.8.5 / 1.9 (Q4 2013) :

" git check-ignore " sigue la misma regla que " git add " y " git status " en el sentido de que el mecanismo de ignorar / excluir no tiene efecto en las rutas que ya están rastreadas.
Con la --no-index " --no-index ", se puede usar para diagnosticar qué rutas que deberían haberse ignorado se agregaron erróneamente al índice .

Consulte commit 8231fa6 de https://github.com/flashydave :

check-ignore actualmente muestra cómo .gitignore reglas .gitignore tratarían las rutas sin .gitignore . Las rutas rastreadas no generan resultados útiles.
Esto evita la depuración de por qué una ruta se hizo un seguimiento inesperado a menos que esa ruta se elimine primero del índice con git rm --cached <path> .

La opción --no-index le dice al comando que omita la verificación de la ruta que está en el índice y, por lo tanto, permite que las rutas rastreadas también se verifiquen.

Si bien este comportamiento se desvía de las características de git add y git status es poco probable que su caso de uso cause confusión al usuario.

Los scripts de prueba se aumentan para comparar esta opción con los ignorados estándar para garantizar el comportamiento correcto.

--no-index::

No mire en el índice al realizar los controles.
Esto puede ser usado:

• para depurar por qué un camino se hizo seguimiento, por ejemplo, git add . y no fue ignorado por las reglas como lo esperaba el usuario o
• al desarrollar patrones, incluida la negación, para hacer coincidir una ruta previamente agregada con git add -f .

Answer 2

No puedo encontrar nada en la página del manual, pero aquí hay una secuencia de comandos rápida y sucia que revisará su archivo en cada directorio principal para ver si se puede agregar. Ejecutarlo en el directorio que contiene el archivo problema como:

test-add.sh STOP_DIR FILENAME

donde STOP_DIR es el directorio de nivel superior del proyecto Git y FILENAME es el nombre del archivo problemático (sin una ruta). Crea un archivo vacío con el mismo nombre en cada nivel de la jerarquía (si no existe) y prueba un git add -n para ver si se puede agregar (se limpia después de sí mismo). Produce algo como:

FAILED:    /dir/1/2/3
SUCCEEDED: /dir/1/2

La secuencia de comandos:

#!/usr/bin/env bash
TOP=$1
FILE=$2
DIR=`pwd`
while : ; do
  TMPFILE=1
  F=$DIR/$FILE
  if [ ! -f $F ]; then
    touch $F
    TMPFILE=0
  fi
  git add -n $F >/dev/null 2>&1
  if [ $? = 0 ]; then
    echo "SUCCEEDED: $DIR"
  else
    echo "FAILED:    $DIR"
  fi
  if [ $TMPFILE = 0 ]; then
    rm $F
  fi
  DIR=${DIR%/*}
  if [ "$DIR" /< "$TOP" ]; then
    break
  fi
done 

Answer 3

Para agregar a la respuesta principal de usar git check-ignore -v filename (gracias BTW) encontré que mi archivo .gitignore estaba bloqueando todo porque había una nueva línea después de un comodín, así que tuve:

* .sublime-project

como ejemplo. Acabo de eliminar la nueva línea, y ¡voilá! Fue arreglado

Answer 4

git check-ignore -v filename

Vea la página del manual para más detalles.

La respuesta original sigue:

git no proporciona actualmente nada como esto. Pero después de ver su pregunta, hice algunas búsquedas en Google y descubrí que en 2009 esta función se solicitó y se implementó parcialmente . Después de leer el hilo, me di cuenta de que no sería demasiado trabajo hacerlo correctamente, así que empecé a trabajar en un parche y espero que termine en uno o dos días. Actualizaré esta respuesta cuando esté lista.

ACTUALIZACIÓN: Wow, eso fue mucho más difícil de lo que esperaba. Las entrañas del manejo excluido de Git son bastante crípticas. De todos modos, aquí hay una serie de compromisos casi terminados que se aplican a la rama master ascendente de hoy. El conjunto de pruebas está completo al 99%, pero aún no he terminado de manejar la opción --stdin . Con suerte lo manejaré este fin de semana y luego enviaré mis parches a la lista de correo de git.

Mientras tanto, definitivamente agradecería las pruebas de cualquiera que sea capaz de hacerlo, simplemente clonar desde mi bifurcación de git , revisar la rama de check-ignore y compilarlo de la forma habitual.

ACTUALIZACIÓN 2: ¡ Está hecho! La última versión está en github según lo indicado anteriormente, y he enviado la serie de parches a la lista de correo de git para su revisión por pares A ver qué piensan ...

ACTUALIZACIÓN 3: Después de varios meses más de piratería / revisiones de parches / discusiones / espera, estoy encantado de poder decir que esta característica ahora ha llegado a la rama master de git , y estará disponible en la próxima versión (1.8.2, esperado 8 de marzo de 2013). Aquí está la página de check-ignore manual . ¡Uf, eso era mucho más trabajo de lo que esperaba!

ACTUALIZACIÓN 4: Si está interesado en la historia completa sobre cómo evolucionó esta respuesta y se implementó la función, consulte el episodio 32 del podcast de GitMinutes .