MISE À JOUR : l'OP Daniel Stutzbach souligne dans les commentaires que cette simple commande a git diff-index
fonctionné pour lui:
git update-index --refresh
git diff-index --quiet HEAD --
( Nornagon mentionne dans les commentaires que, s'il y a des fichiers qui ont été touchés, mais dont le contenu est le même que dans l'index, vous devrez exécuter git update-index --refresh
avant git diff-index
, sinon vous diff-index
rapporterez à tort que l'arborescence est sale)
Vous pouvez alors voir " Comment vérifier si une commande a réussi? " Si vous l'utilisez dans un script bash:
git diff-index --quiet HEAD -- || echo "untracked"; // do something about it
Note: comme commenté par Anthony Sottile
git diff-index HEAD ...
échouera sur une branche qui n'a pas de validations (comme un référentiel nouvellement initialisé).
Une solution de contournement que j'ai trouvée estgit diff-index $(git write-tree) ...
Et haridsv
souligne dans les commentaires que git diff-files
sur un nouveau fichier ne le détecte pas comme un diff.
L'approche la plus sûre semble être d'exécuter git add
d'abord la spécification de fichier, puis de l'utiliser git diff-index
pour voir si quelque chose a été ajouté à l'index avant de s'exécuter git commit
.
git add ${file_args} && \
git diff-index --cached --quiet HEAD || git commit -m '${commit_msg}'
Et 6502 rapports dans les commentaires:
Un problème que j'ai rencontré est celui git diff-index
qui indiquera qu'il y a des différences alors qu'en fait il n'y en a pas, sauf pour les horodatages des fichiers.
Exécuter git diff
une fois résout le problème (assez surprenant, git diff
cela change en fait le contenu du bac à sable, ce qui signifie ici .git/index
)
Ces problèmes d'horodatage peuvent également se produire si git s'exécute dans docker .
Réponse originale:
"Par programme" signifie ne jamais se fier aux commandes en porcelaine .
Comptez toujours sur les commandes de plomberie .
Voir aussi " Recherche d'un index sale ou de fichiers non suivis avec Git " pour des alternatives (comme git status --porcelain
)
Vous pouvez vous inspirer de la nouvelle " require_clean_work_tree
fonction " qui s'écrit au moment où nous parlons ;) (début octobre 2010)
require_clean_work_tree () {
# Update the index
git update-index -q --ignore-submodules --refresh
err=0
# Disallow unstaged changes in the working tree
if ! git diff-files --quiet --ignore-submodules --
then
echo >&2 "cannot $1: you have unstaged changes."
git diff-files --name-status -r --ignore-submodules -- >&2
err=1
fi
# Disallow uncommitted changes in the index
if ! git diff-index --cached --quiet HEAD --ignore-submodules --
then
echo >&2 "cannot $1: your index contains uncommitted changes."
git diff-index --cached --name-status -r --ignore-submodules HEAD -- >&2
err=1
fi
if [ $err = 1 ]
then
echo >&2 "Please commit or stash them."
exit 1
fi
}