Expliquer quelle règle gitignore ignore mon fichier

Question

Existe-t-il un moyen de savoir pourquoi un fichier est ignoré par git (c'est-à-dire quelle règle dans un fichier .gitignore fait que le fichier est ignoré) ?

Imaginez que j'ai ceci (ou un scénario beaucoup plus complexe, avec des centaines de dossiers et des dizaines de .gitignore des fichiers :

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

Si je cours git add folder/subfolder/file.txt git peut se plaindre qu'elle est ignorée :

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

Y a-t-il un moyen de savoir lequel de tous les possibles .gitignore avoir une règle pour ignorer ce fichier, et aussi afficher la règle ? Par exemple :

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.

Ou juste :

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

Answer 1

git check-ignore -v filename

Ver la page de manuel pour plus de détails.

La réponse originale suit :

git ne fournit actuellement rien de tel. Mais après avoir vu votre question, j'ai fait un peu de recherche sur Google et j'ai trouvé qu'en 2009 cette fonctionnalité a été demandée et partiellement mise en œuvre . Après avoir lu le fil de discussion, j'ai réalisé qu'il ne serait pas trop difficile de le faire correctement. J'ai donc commencé à travailler sur un patch et j'espère qu'il sera terminé d'ici un jour ou deux. Je mettrai à jour cette réponse lorsqu'elle sera prête.

UPDATE : Wow, c'était beaucoup plus difficile que je ne le pensais. Les entrailles de git La gestion des exclusions de l'entreprise est assez énigmatique. Quoi qu'il en soit, voici un presque série de commits finis qui s'appliquent à l'amont d'aujourd'hui master branche. La suite de tests est complète à 99%, mais je n'ai pas fini de traiter les --stdin pour le moment. J'espère y parvenir ce week-end, puis soumettre mes correctifs à la liste de diffusion git.

Entre-temps, j'accueillerais volontiers les tests de tous ceux qui sont en mesure de le faire - il suffit de cloner à partir de mon git fourchette , consultez le check-ignore et le compiler normalement.

UPDATE 2 : C'est fait ! La dernière version est sur github comme indiqué ci-dessus, et j'ai soumis la série de patchs à la liste de diffusion git pour un examen par les pairs. Voyons ce qu'ils pensent ...

UPDATE 3 : Après plusieurs mois supplémentaires de piratage, de révision des correctifs, de discussions et d'attente, je suis ravi de pouvoir dire que cette fonctionnalité a maintenant atteint la version de git master branche et sera disponible dans la prochaine version (1.8.2, attendue le 8 mars 2013). Voici la check-ignore page de manuel . Ouf, c'était beaucoup plus de travail que je ne le pensais !

UPDATE 4 : Si vous souhaitez connaître l'histoire complète de l'évolution de cette réponse et de la mise en œuvre de cette fonctionnalité, consultez le site suivant épisode n°32 du podcast GitMinutes .

Answer 2

Mise à jour de git 2.8 (mars 2016) :

GIT_TRACE_EXCLUDE=1 git status

Voir " Un moyen de valider .gitignore fichier "

C'est un complément à la git check-ignore -v décrite ci-dessous.

---

Réponse originale : Sept 2013 (git 1.8.2, puis 1.8.5+) :

git check-ignore s'améliore encore en git 1.8.5/1.9 (Q4 2013) :

" git check-ignore "suit la même règle que " git add " et " git status "en ce sens que le mécanisme d'exclusion ou d'ignorance ne prend pas effet sur les chemins qui sont déjà suivis.
Avec " --no-index "Il peut être utilisé pour diagnostiquer les chemins qui auraient dû être ignorés et qui ont été ajoutés par erreur à l'index. .

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

check-ignore montre actuellement comment .gitignore traiterait les chemins non tracés. Les chemins suivis ne génèrent pas de résultats utiles.
Cela empêche le débogage de la raison pour laquelle un chemin est devenu suivi de manière inattendue, à moins que ce chemin ne soit d'abord retiré de l'index avec git rm --cached <path> .

L'option --no-index indique à la commande de ne pas vérifier si le chemin est dans l'index et permet donc de vérifier également les chemins suivis.

Bien que ce comportement s'écarte des caractéristiques du git add y git status son cas d'utilisation n'est pas susceptible de causer une quelconque confusion chez les utilisateurs.

Les scripts de test sont complétés pour vérifier cette option par rapport aux ignorances standard afin de garantir un comportement correct.

---

--no-index::

Ne regardez pas dans l'index lorsque vous effectuez les contrôles.
Cela peut être utilisé :

• pour déboguer la raison pour laquelle un chemin a été suivi par exemple par git add . et n'a pas été ignoré par les règles comme l'utilisateur s'y attendait ou
• lors du développement de motifs incluant la négation pour correspondre à un chemin précédemment ajouté avec git add -f .

Answer 3

Ce n'est peut-être pas .gitignore -- 3 raisons possibles d'ignorer

Un fichier peut être ignoré pour les raisons suivantes :

1. .gitignore
2. git update-index --skip-worktree
3. git update-index --assume-unchanged

De plus, un fichier peut être ignoré s'il se trouve dans le répertoire .gitignore ET déjà mis en place dans l'index/cache.

Pour vérifier les cas énumérés ci-dessus :

1. Pour les deux cas de .gitignore exclut, compare le résultat de :

   • git check-ignore --verbose --non-matching --no-index file1 file2 file3
   • git check-ignore --verbose --non-matching file1 file2 file3

2. git ls-files file1 file2 file3 | grep -E '^S'

3. git ls-files file1 file2 file3 | grep -E '^[[:lower:]]'

C'est trop dur, donnez-moi juste un alias !

Les pseudonymes suivants couvriront tous les cas énumérés ci-dessus :

ignore = !"bash -c 'diff --unified=999999999 --color=always <(echo a; git check-ignore --verbose --non-matching --no-index . \"$@\") <(echo b; git check-ignore --verbose --non-matching . \"$@\")' - \"$@\" | tail -n+7; git hidden \"$@\" # Show ignore status of arguments. Files included by index are tagged with prepended '+'."
hidden = !"git ls-files -v -- \"$@\"| grep -E '^(S|[[:lower:]])' # S means update-index --skip-worktree, and lower first letter means --assume-unchanged."

Le commentaire et la finale " font partie de la ligne à copier dans votre .gitconfig .

Utilisation :

git ignore file1 file2 file3

Answer 4

Je ne trouve rien dans la page de manuel mais voici un script rapide et sale qui va vérifier votre fichier dans chaque répertoire parent pour voir s'il peut être git-add'ed. Exécutez-le dans le répertoire contenant le fichier problématique comme :

test-add.sh STOP_DIR FILENAME

donde STOP_DIR est le répertoire de premier niveau du projet Git et FILENAME est le nom du fichier problématique (sans chemin). Il crée un fichier vide du même nom à chaque niveau de la hiérarchie (s'il n'existe pas) et tente un git add -n pour voir s'il peut être ajouté (il nettoie après lui-même). Il produit quelque chose comme :

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

Le script :

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

Contexte : J'ai eu un problème très similaire, je ne pouvais pas trouver quelle règle ignorait mon fichier/dossier. J'ai essayé
git check-ignore -v filename
mais cela ne m'a pas donné de résultat, ou le résultat était un numéro de ligne avec une ligne blanche dans mon fichier .gitignore.
Le problème était donc que mon fichier n'était pas ignoré par mon fichier .gitignore local, mais par mon fichier core.excludesfile local (qui n'est pas inclus dans mon dépôt).

Solución : J'ai cherché l'emplacement du fichier avec cette commande :
git config core.excludesfile
puis je l'ai ouvert et supprimé la ligne problématique et c'est tout.

Référence : Vous pouvez aussi jeter un coup d'oeil aquí pour des explications supplémentaires.