Le statut de Git montre les fichiers modifiés mais Git Diff ne le fait pas
J'ai jeté un coup d'œil à toutes les questions similaires, mais j'ai vérifié deux fois et quelque chose d'étrange se produit.
Sur un serveur (Solaris avec git 1.8.1), j'ai cloné le référentiel git, puis copié le dossier .git dans mes fichiers live existants. Cela fonctionnait parfaitement, je pouvais courir
git status
ensuite
git diff [filename]
pour vérifier tous les fichiers qui étaient différents.
Sur un autre serveur (Solaris avec git 1.7.6), je fais exactement la même chose cependant.
git diff [filename]
ne montre rien, même si le contenu du fichier est vraiment différent. J'ai également essayé d'ajouter un nouveau fichier, de le valider puis de le modifier. Même problème, git status montre le fichier modifié mais git diff ne montre rien. Si je télécharge le fichier modifié et exécute un diff localement, je reçois une sortie diff.
J'ai ajouté le fichier au index :
git add file_name
et ensuite couru:
git diff --cached file_name
Vous pouvez voir la description de git diff ici .
Si vous avez besoin d’annuler votre ajout à git, veuillez consulter le lien suivant: Comment annuler l’ajout de git avant le commit?
Il y a quelques raisons pour lesquelles git status peut montrer une différence mais git diff ne le peut pas.
Le mode (bits d'autorisation) du fichier a changé, par exemple de 777 à 700.
Le style de saut de ligne est passé de CRLF (DOS) à LF (UNIX)
Le moyen le plus simple de savoir ce qui s'est passé est d'exécuter git format-patch HEAD^ et de voir ce que dit le correctif généré.
Pour moi, cela avait quelque chose à voir avec les autorisations de fichiers. Quelqu'un avec Mac/Linux sur mon projet semble valider certains fichiers avec des autorisations autres que celles par défaut que mon client Windows Git n'a pas réussi à reproduire. La solution pour moi était de dire à git d’ignorer les autorisations de fichiers:
git config core.fileMode false
Autres informations: Comment puis-je faire en sorte que Git ignore les changements de mode de fichier (chmod)?
J'ai eu un problème où des centaines de fins de lignes ont été modifiées par certains programmes et git diff a répertorié tous les fichiers sources modifiés. Après avoir corrigé les fins de ligne, le statut de git répertorie toujours les fichiers modifiés.
J'ai pu résoudre ce problème en ajoutant tous les fichiers à indexer, puis en réinitialisant l'index.
git add -A
git reset
core.filemode était défini sur false.
Je soupçonne que quelque chose ne va pas avec votre installation de git ou votre référentiel.
Essayez de courir:
GIT_TRACE=2 git <command>
Voyez si vous obtenez quelque chose d'utile. Si cela ne vous aide pas, il suffit de regarder et de voir ce qui ne va pas:
strace git <command>
J'ai eu un problème similaire: git diff montrerait des différences, mais git diff <filename> ne le ferait pas. Il s'est avéré que j'ai défini LESS sur une chaîne contenant -F (--quit-if-one-screen). La suppression de ce drapeau a résolu le problème.
Couru dans ce problème. Mon cas était similaire au numéro LESS publié par @rcwxok.
Dans mon cas, je règle la variable PAGERenvironnement sur PAGER='less -RSF'.
Cependant, contrairement aux réponses précédentes, je ne voulais pas supprimer l'option -F, car je la mettais explicitement dans cet espoir d'éviter d'afficher le diff dans less s'il est plus court qu'un écran.
Pour obtenir le résultat souhaité, au lieu de supprimer -F, j'ai ajouté -X: PAGER='less -RSFX'. Cela a résolu le problème de git diff et a également évité d'afficher des différences courtes avec less.
J'espère que ça aide quelqu'un.
Réponse courte
Exécuter git add aide parfois.
Exemple
Le statut de Git montre les fichiers modifiés et le diff de Git ne montre rien ...
> git status
On branch master
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: package.json
no changes added to commit (use "git add" and/or "git commit -a")
> git diff
>
... exécuter git add résout l'incohérence.
> git add
> git status
On branch master
nothing to commit, working directory clean
>
Je viens de courir dans un problème similaire. git diff file ne montre rien car j'ai ajouté un fichier à l'index git avec une partie de son nom en majuscule: GeoJSONContainer.js. Ensuite, je l'ai renommé en GeoJsonContainer.js et les modifications ne sont plus suivies. git diff GeoJsonContainer.js ne montrait rien. J'ai dû supprimer le fichier de l'index avec un indicateur de force, puis rajouter le fichier:
git rm -f GeoJSONContainer.js
git add GeoJSONContainer.js
Vous n'avez pas vraiment posé de question, mais comme il s'agit d'un cas d'usage général, j'utilise souvent ce que je fais. Vous pouvez essayer cela vous-même et voir si l'erreur persiste.
Mon hypothèse sur votre cas d'utilisation: vous avez un répertoire existant contenant des fichiers et des répertoires et vous souhaitez maintenant le convertir en un référentiel git qui est cloné ailleurs sans changer les données de votre répertoire actuel.
Il y a vraiment deux façons.
Clone repo - mv .git - réinitialisation de git - hard
Vous avez utilisé cette méthode: pour cloner le référentiel existant dans un répertoire vide, puis déplacez le répertoire .git dans le répertoire de destination. Pour travailler sans problèmes, cela nécessite généralement de lancer
git reset --hard
Cependant, cela modifierait l'état des fichiers de votre répertoire actuel. Vous pouvez essayer ceci sur une copie complète/rsync de votre répertoire et étudier les modifications. Au moins après cela, vous ne devriez plus voir les différences entre git log et status.
Init new nouveau repo - pointer sur Origin
La seconde est moins dérangeante: entrez votre destination et démarrez un nouveau dépôt avec
git init
Ensuite, vous indiquez à ce nouveau référentiel qu’il a un ancêtre ailleurs:
git remote add Origin original_git_repo_path
Puis en toute sécurité
git fetch Origin master
copier sur les données sans changer vos fichiers locaux. Tout devrait bien se passer maintenant.
Je recommande toujours le deuxième moyen pour être moins sujet aux erreurs.
J'ai eu ce même problème décrit de la manière suivante: Si j'ai tapé
$ git diff
git est simplement retourné à l'invite sans erreur.
Si j'ai tapé
$ git diff <filename>
git est simplement retourné à l'invite sans erreur.
Enfin, en lisant autour de moi, j'ai remarqué que git diff appelle en fait le mingw64\bin\diff.exe pour effectuer le travail.
Voici le deal. Je suis sous Windows et j’ai installé un autre utilitaire bash, qui a changé mon chemin afin de ne plus pointer vers mon répertoire mingw64\bin.
Donc, si vous tapez: git diff et qu’il revient simplement à l’invite, vous risquez d’avoir ce problème.
Le fichier diff.exe actuel géré par git se trouve dans votre répertoire mingw64\bin
Enfin, pour résoudre ce problème, j'ai en fait copié mon répertoire mingw64\bin à l'emplacement dans lequel git le cherchait. Je l'ai essayé et cela ne fonctionnait toujours pas.
Ensuite, j'ai fermé ma fenêtre git bash et je l'ai rouverte, puis je suis allée sur mon même dépôt qui échouait et maintenant cela fonctionne.
J'espère que ça va t'aider aussi.
Je suis tombé sur ce problème à nouveau. Mais cette fois, cela s'est produit pour une raison différente. J'avais copié des fichiers dans le référentiel pour écraser les versions précédentes. Maintenant, je peux voir que les fichiers sont modifiés, mais diff ne renvoie pas les diff.
Par exemple, j'ai un fichier mainpage.xaml. Dans l'explorateur de fichiers, j'ai collé un nouveau fichier mainpage.xaml par-dessus celui de mon référentiel actuel. J'ai fait le travail sur une autre machine et juste collé le fichier ici.
Le fichier montre modifié, mais lorsque je lance git diff, il ne montrera pas les modifications. C'est probablement parce que le fichier info du fichier a changé et que git sait que ce n'est pas vraiment le même fichier. Intéressant.
Vous pouvez voir que lorsque je lance diff sur le fichier, il ne montre rien, renvoie simplement l'invite.
Comme déjà noté ci-dessus , cette situation peut survenir en raison de problèmes de fin de ligne (CRLF vs LF). J'ai résolu ce problème (sous la version 2.22.0 de git) avec cette commande:
git add --renormalize .
Selon le manuel:
--renormalize
Apply the "clean" process freshly to all tracked files to
forcibly add them again to the index. This is useful after
changing core.autocrlf configuration or the text attribute in
order to correct files added with wrong CRLF/LF line endings.
This option implies -u.