web-dev-qa-db-fra.com

Expliquer quelle règle gitignore ignore mon fichier

Existe-t-il un moyen de voir pourquoi certains fichiers sont ignorés par git (c'est-à-dire quelle règle dans un fichier .gitignore le fichier est en train de l'ignorer)?

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

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

Si je cours git add folder/subfolder/file.txt _ git peut se plaindre d'être ignoré:

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

Est-il possible de savoir lequel de tous les .gitignore a une règle pour ignorer ce fichier et aussi pour afficher la règle? Comme:

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
gitgitignore
282
Carlos Campderrós
git check-ignore -v filename

Voir 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 quelques recherches sur Google et découvert qu'en 2009 cette fonctionnalité a été demandée et partiellement mise en œuvre . Après avoir lu le fil de discussion, je me suis rendu compte que le faire correctement ne nécessiterait pas trop de travail. J'ai donc commencé à travailler sur un correctif et j'espère le terminer dans un ou deux jours. Je mettrai à jour cette réponse quand elle sera prête.

UPDATE: Wow, c'était beaucoup plus dur que ce à quoi je m'attendais. Les entrailles du traitement d'exclusion de git sont assez cryptiques. Quoi qu'il en soit, voici an presque série terminée de commits qui s'appliquent à la branche amont actuelle master. La suite de tests est terminée à 99%, mais je n'ai pas fini de manipuler le --stdin option encore. Si tout va bien, je vais y arriver ce week-end, puis je soumettrai mes correctifs à la liste de diffusion git.

En attendant, je serais ravi de pouvoir tester ceux qui sont capables de le faire - il suffit de cloner à partir de mon git fork , consultez le check-ignore branchez et compilez-le normalement.

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

MISE À JOUR 3: Après plusieurs mois supplémentaires de piratage informatique/critiques de patch/discussions/attente, je suis ravi de pouvoir dire que this Cette fonctionnalité a maintenant atteint la branche master de git et sera disponible dans la prochaine version (1.8.2, attendue le 8 mars 2013). Voici le check-ignore page de manuel . Ouf, c'était beaucoup plus de travail que prévu!

MISE À JOUR 4: Si l'histoire complète vous explique comment cette réponse a évolué et que la fonctionnalité a été mise en œuvre, consultez épisode # 32 du podcast GitMinutes .

590
Adam Spiers

Mise à jour de git 2.8 (mars 2016):

GIT_TRACE_EXCLUDE=1 git status

Voir " n moyen de valider .gitignore fichier "

C'est complémentaire à la git check-ignore -v décrit ci-dessous.

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

git check-ignore _ améliore à nouveau dans 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 que le mécanisme ignorer/exclure ne prend pas effet sur les chemins déjà suivis.
Avec "--no-index ", il peut être utilisé pour diagnostiquer quels chemins qui auraient dû être ignorés ont été ajoutés par erreur à l’index .

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

check-ignore montre actuellement comment .gitignore _ règles traiteraient les chemins non suivis. Les chemins suivis ne génèrent pas de sortie utile.
Ceci empêche le débogage de la raison pour laquelle un chemin est suivi inopinément à moins que ce chemin ne soit d'abord supprimé de l'index avec git rm --cached <path>.

L'option --no-index indique à la commande de contourner la vérification du chemin figurant dans l'index, ce qui permet également de vérifier les chemins suivis.

Bien que ce comportement diffère des caractéristiques de git add et git status _ il est peu probable que son cas d'utilisation crée la confusion chez l'utilisateur.

Les scripts de test sont augmentés pour comparer cette option à la norme ignore pour garantir un comportement correct.

--no-index::

Ne regardez pas dans l'index lors des vérifications.
Ceci peut être utilisé:

  • pour déboguer pourquoi un chemin est devenu suivi, par exemple git add . et n'a pas été ignoré par les règles attendues par l'utilisateur ou
  • lors du développement de modèles incluant la négation pour correspondre à un chemin précédemment ajouté avec git add -f.
17
VonC

Je ne trouve rien dans la page de manuel, mais voici un script rapide et sale qui vérifie votre fichier dans chaque répertoire parent pour voir s'il peut être ajouté à git. Exécutez-le dans le répertoire contenant le fichier problème sous:

test-add.sh STOP_DIR FILENAME

où STOP_DIR est le répertoire de niveau supérieur du projet Git et FILENAME est le nom du fichier posant problème (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 se nettoie lui-même). Il génère quelque chose comme:

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

Le scénario:

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

Pour ajouter à la réponse principale d’utiliser git check-ignore -v filename (merci BTW) J'ai constaté que mon fichier .gitignore bloquait tout, car il y avait une nouvelle ligne après un caractère générique, donc j'avais:

* .sublime-project

par exemple. Je viens de supprimer la nouvelle ligne, et le tour est joué! C'était réparé.

1
rekordboy