Spiega quale regola del gitignore sta ignorando il mio file

C’è un modo per capire perché alcuni file vengono ignorati da git (cioè quale regola in un file .gitignore sta causando l’ .gitignore del file)?

Immagina di avere questo (o uno scenario molto più complesso, con centinaia di cartelle e decine di file .gitignore :

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

Se git add folder/subfolder/file.txt git potrebbe lamentarsi di essere ignorato:

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

C’è un modo per sapere quale tra tutti i possibili .gitignore ha una regola per ignorare questo file e mostrare anche la regola? Piace:

 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 semplicemente:

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

 git check-ignore -v filename 

Vedi la pagina man per maggiori dettagli.

La risposta originale segue:

git al momento non fornisce nulla di simile. Ma dopo aver visto la tua domanda ho fatto qualche ricerca su google e ho scoperto che nel 2009 questa funzione è stata richiesta e parzialmente implementata . Dopo aver letto il thread, mi sono reso conto che non sarebbe stato troppo lavoro per farlo correttamente, quindi ho iniziato a lavorare su una patch e spero di averlo finito nei prossimi giorni o due. Aggiornerò questa risposta quando sarà pronta.

AGGIORNAMENTO: Wow, è stato molto più difficile di quanto mi aspettassi. Le interiora del trattamento di esclusione di Git sono piuttosto criptici. Ad ogni modo, ecco una serie di commit quasi finiti che si applicano al ramo master di oggi. La suite di test è completa al 99%, ma non ho ancora finito di gestire l’opzione --stdin . Spero di essere in grado di farlo questo fine settimana e di inviare le mie patch alla mailing list git.

Nel frattempo, darei il benvenuto ai test di chiunque sia in grado di farlo – basta clonare dal mio fork git , controllare il ramo check-ignore e compilarlo normalmente.

AGGIORNAMENTO 2: è fatto! L’ultima versione è su github come sopra, e ho inviato la serie di patch alla mailing list git per la revisione tra pari. Vediamo cosa pensano …

AGGIORNAMENTO 3: Dopo diversi mesi di hacking / patch review / discussion / waiting, sono lieto di poter dire che questa funzione ha ora raggiunto il ramo master di git e sarà disponibile nella prossima versione (1.8.2, atteso 8 marzo 2013). Ecco la pagina di manuale di check-ignore . Phew, è andata molto più di quanto mi aspettassi!

AGGIORNAMENTO 4: Se sei interessato alla storia completa su come questa risposta si è evoluta e la funzionalità è stata implementata, dai un’occhiata all’episodio # 32 del podcast GitMinutes .

Aggiornamento git 2.8 (marzo 2016):

 GIT_TRACE_EXCLUDE=1 git status 

Vedi ” Un modo per convalidare il file .gitignore

Questo è complementare al git check-ignore -v descritto sotto.


Risposta originale: settembre 2013 (git 1.8.2, poi 1.8.5+):

git check-ignore migliora di nuovo in git 1.8.5 / 1.9 (Q4 2013) :

git check-ignore ” segue la stessa regola di ” git add ” e ” git status ” in quanto il meccanismo ignore / exclude non ha effetto sui percorsi già tracciati.
Con l’opzione ” --no-index “, può essere usato per diagnosticare quali percorsi che avrebbero dovuto essere ignorati sono stati erroneamente aggiunti all’indice .

Vedi commit 8231fa6 da https://github.com/flashydave :

check-ignore attualmente mostra come le regole .gitignore trattano i percorsi non tracciati. I percorsi tracciati non generano output utili.
Ciò impedisce il debug del motivo per cui un percorso è stato tracciato in modo imprevisto a meno che quel percorso non sia prima rimosso dall’indice con git rm --cached .

L’opzione --no-index dice al comando di ignorare il controllo del percorso nell’indice e quindi permette di controllare anche i percorsi tracciati.

Sebbene questo comportamento si discosti dalle caratteristiche di git add e git status è improbabile che il suo use case causi confusione all’utente.

Gli script di test sono stati potenziati per verificare questa opzione rispetto alle ignorazioni standard per garantire un comportamento corretto.


 --no-index:: 

Non guardare nell’indice quando si effettuano i controlli.
Questo può essere usato:

  • per eseguire il debug del motivo per cui un tracciamento è stato tracciato, ad esempio git add . e non è stato ignorato dalle regole come previsto dall’utente o
  • quando sviluppi modelli che includono la negazione per abbinare un percorso precedentemente aggiunto con git add -f .

Non riesco a trovare nulla nella pagina man, ma qui è uno script veloce e sporco che controllerà il tuo file in ogni directory padre per vedere se può essere git-add’ed. Eseguilo nella directory contenente il file del problema come:

 test-add.sh STOP_DIR FILENAME 

dove STOP_DIR è la directory di livello superiore del progetto Git e FILENAME è il nome del file del problema (senza un percorso). Crea un file vuoto con lo stesso nome a ogni livello della gerarchia (se non esiste) e prova un git add -n per vedere se può essere aggiunto (si ripulisce dopo se stesso). Produce qualcosa come:

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

Il copione:

 #!/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 

Per aggiungere alla risposta principale dell’uso di git check-ignore -v filename (grazie a BTW) ho scoperto che il mio file .gitignore stava bloccando tutto perché c’era una newline dopo un carattere jolly, quindi avevo:

* .sublime-project

come esempio. Ho appena rimosso la nuova riga e voilà! È stato risolto