Vérification d'un index sale ou de fichiers non suivis avec Git

Question

Comment puis-je vérifier si j'ai des modifications non validées dans mon dépôt git :

1. Modifications ajoutées à l'index mais non validées
2. Fichiers non suivis

à partir d'un script ?

git-status semble toujours retourner zéro avec la version 1.6.4.2 de git.

Answer 1

La clé d'un "scripting" fiable de Git est d'utiliser les commandes de "plomberie".

Les développeurs prennent soin, lorsqu'ils modifient les commandes de plomberie, de s'assurer qu'elles fournissent des interfaces très stables (c'est-à-dire qu'une combinaison donnée d'état du dépôt, de stdin, d'options de ligne de commande, d'arguments, etc. produira la même sortie dans toutes les versions de Git où la commande/option existe). De nouvelles variations de sortie dans les commandes de plomberie peuvent être introduites via de nouvelles options, mais cela ne peut pas introduire de problèmes pour les programmes qui ont déjà été écrits contre des versions plus anciennes (ils n'utiliseraient pas les nouvelles options, puisqu'elles n'existaient pas (ou du moins n'étaient pas utilisées) au moment où le script a été écrit).

Malheureusement, les commandes Git "de tous les jours" sont les commandes "en porcelaine", de sorte que la plupart des utilisateurs de Git ne sont pas familiers avec les commandes de plomberie. La distinction entre les commandes "porcelaine" et les commandes "plomberie" est faite dans les principaux éléments suivants page de manuel git (voir les sous-sections intitulées Commandes de haut niveau (porcelaine) y Commandes de bas niveau (plomberie) .

---

Pour vous renseigner sur les modifications non admises, vous aurez probablement besoin de git diff-index (comparer l'index (et peut-être les éléments suivis de l'arbre de travail) avec d'autres arbres (par ex. HEAD )), peut-être git diff-files (comparer l'arbre de travail à l'index), et éventuellement git ls-files (liste des fichiers ; par exemple, liste des fichiers non suivis, non ignorés).

(Notez que dans les commandes ci-dessous, HEAD -- est utilisé à la place de HEAD car sinon la commande échoue s'il existe un fichier nommé HEAD .)

Pour vérifier si un dépôt a des changements indexés (pas encore livrés), utilisez ceci :

git diff-index --quiet --cached HEAD --

• S'il sort avec 0 puis il n'y a pas eu de différences ( 1 signifie qu'il y avait des différences).

Pour vérifier si un arbre de travail a des changements qui pourraient être mis en scène :

git diff-files --quiet

• Le code de sortie est le même que pour git diff-index ( 0 == pas de différences ; 1 == différences).

Pour vérifier si la combinaison de l'index et des fichiers suivis dans l'arborescence de travail a changé par rapport à HEAD :

git diff-index --quiet HEAD --

• C'est comme une combinaison des deux précédentes. La principale différence est qu'il ne signalera toujours "aucune différence" si vous avez une modification échelonnée que vous avez "annulée" dans l'arbre de travail (retour au contenu qui se trouve dans l'arbre de travail). HEAD ). Dans cette même situation, les deux commandes distinctes renverraient toutes deux le rapport "différences présentes".

Vous avez également mentionné les fichiers non tracés. Vous pouvez vouloir dire "non suivis et non ignorés", ou vous pouvez vouloir dire simplement "non suivis" (y compris les fichiers ignorés). Dans tous les cas, git ls-files est l'outil idéal pour ce travail :

Pour "untracked" (inclura les fichiers ignorés, s'ils sont présents) :

git ls-files --others

Pour "sans trace et sans signe" :

git ls-files --exclude-standard --others

Ma première idée est de vérifier si ces commandes ont un résultat :

test -z "$(git ls-files --others)"

• S'il sort avec 0 alors il n'y a pas de fichiers non tracés. S'il sort avec 1 alors il y a des fichiers non tracés.

Il y a une petite chance que cela se traduise par des sorties anormales de git ls-files en rapports "no untracked files" (les deux résultent en des sorties non nulles de la commande ci-dessus). Une version un peu plus robuste pourrait ressembler à ceci :

u="$(git ls-files --others)" && test -z "$u"

• L'idée est la même que la commande précédente, mais elle permet aux erreurs inattendues de git ls-files pour se propager à l'extérieur. Dans ce cas, une sortie non nulle pourrait signifier "il y a des fichiers non suivis" ou cela pourrait signifier qu'une erreur s'est produite. Si vous voulez que le résultat "erreur" soit combiné avec le résultat "pas de fichiers non suivis" à la place, utilisez test -n "$u" (où la sortie de 0 signifie "quelques fichiers non suivis", et un chiffre différent de zéro signifie une erreur ou "aucun fichier non suivi").

Une autre idée est d'utiliser --error-unmatch pour provoquer une sortie non nulle lorsqu'il n'y a pas de fichiers non suivis. Cela présente également le risque de confondre "aucun fichier non suivi" (exit 1 ) avec "une erreur s'est produite" (sortie non nulle, mais probablement 128 ). Mais la vérification de 0 vs. 1 par rapport aux codes de sortie non nuls est probablement assez robuste :

git ls-files --others --error-unmatch . >/dev/null 2>&1; ec=$?
if test "$ec" = 0; then
    echo some untracked files
elif test "$ec" = 1; then
    echo no untracked files
else
    echo error from ls-files
fi

Tout ce qui précède git ls-files les exemples peuvent prendre --exclude-standard si vous voulez considérer uniquement les fichiers non suivis et non ignorés.

Answer 2

Bon timing ! J'ai écrit un article de blog sur ce sujet il y a quelques jours, lorsque j'ai découvert comment ajouter des informations sur le statut de git à mon invite.

Voilà ce que je fais :

1. Pour l'état sale :

   # Returns "*" if the current git branch is dirty.
   function evil_git_dirty {
     [[ $(git diff --shortstat 2> /dev/null | tail -n1) != "" ]] && echo "*"
   }

2. Pour les fichiers non suivis (Notez le --porcelain pour git status ce qui vous donne une sortie agréable à analyser) :

   # Returns the number of untracked files
   
   function evil_git_num_untracked_files {
     expr `git status --porcelain 2>/dev/null| grep "^??" | wc -l` 
   }

Bien que git diff --shortstat est plus pratique, vous pouvez également utiliser git status --porcelain pour récupérer les fichiers sales :

# Get number of files added to the index (but uncommitted)
expr $(git status --porcelain 2>/dev/null| grep "^M" | wc -l)

# Get number of files that are uncommitted and not added
expr $(git status --porcelain 2>/dev/null| grep "^ M" | wc -l)

# Get number of total uncommited files
expr $(git status --porcelain 2>/dev/null| egrep "^(M| M)" | wc -l)

Note : Le 2>/dev/null filtre les messages d'erreur afin que vous puissiez utiliser ces commandes sur des répertoires non git. (Elles renverront simplement 0 pour le décompte des fichiers).

Modifier :

Voici les postes :

Ajout d'informations sur l'état de Git à l'invite de votre terminal

Amélioration de l'invite Shell compatible avec Git

Answer 3

En supposant que vous êtes sur git 1.7.0 ou plus...

Après avoir lu toutes les réponses sur cette page et après avoir fait quelques essais, je pense que la méthode qui présente la bonne combinaison entre exactitude et brièveté est la suivante :

test -n "$(git status --porcelain)"

Bien que git permette beaucoup de nuances entre ce qui est suivi, ignoré, non suivi mais non ignoré, et ainsi de suite, je crois que le cas d'utilisation typique est l'automatisation de build scripts, où vous voulez tout arrêter si votre checkout n'est pas propre.

Dans ce cas, il est logique de simuler ce que le programmeur ferait : tapez git status et regardez la sortie. Mais nous ne voulons pas compter sur l'apparition de mots spécifiques, nous utilisons donc la fonction --porcelain mode introduit dans la version 1.7.0 ; lorsqu'il est activé, un répertoire propre n'entraîne aucune sortie.

Ensuite, nous utilisons test -n pour voir s'il y a eu une sortie ou pas.

Cette commande retournera 1 si le répertoire de travail est propre et 0 s'il y a des changements à valider. Vous pouvez modifier le -n à un -z si vous voulez le contraire. C'est utile pour enchaîner cela à une commande dans un script. Par exemple :

test -z "$(git status --porcelain)" || red-alert "UNCLEAN UNCLEAN"

Ceci dit effectivement "soit il n'y a pas de changements à faire, soit il faut déclencher une alarme" ; cette ligne unique peut être préférable à une déclaration if selon le script que vous écrivez.

Answer 4

Une mise en œuvre de VonC La réponse de la Commission :

if [[ -n $(git status --porcelain) ]]; then echo "repo is dirty"; fi

Answer 5

Pourquoi ne pas encapsuler ' git status avec un script qui :

• va analyser la sortie de cette commande
• retournera le code d'erreur approprié en fonction de ce dont vous avez besoin.

De cette façon, vous pouvez utiliser ce statut "amélioré" dans votre script.

---

Comme 0xfe mentionne dans son excellente réponse , git status --porcelain est instrumental dans toute solution basée sur script.

--porcelain

Donner la sortie dans un format stable et facile à analyser pour les scripts.
Actuellement, il est identique à --short output mais il est garanti qu'il ne changera pas à l'avenir, ce qui le rend sûr pour les scripts.