Le statut Git montre les fichiers comme modifiés même si le contenu est le même

J'ai reçu une vérification git de quelqu'un d'autre et j'essaie de valider les modifications non mises en scène dans le référentiel local. Cependant, beaucoup de fichiers (sinon tous) apparaissent comme modifiés même si le contenu est exactement le même.

J'ai déjà mis core.fileModeà false et également mis core.autocrlfà false, sans succès.

Il convient de mentionner que le dépôt Git que j'ai reçu provenait de quelqu'un utilisant Windows, alors que j'utilise Linux.

Que puis-je faire pour valider les modifications réelles ?

EDIT: sortie de git config -l:

user.name=Aron Rotteveel
user.email=<removed>
color.diff=auto
color.status=auto
color.branch=auto
color.interactive=auto
color.ui=true
color.pager=true
color.branch.current=yellow reverse
color.branch.local=yellow
color.branch.remote=green
color.diff.meta=yellow bold
color.diff.frag=magenta bold
color.diff.old=red bold
color.diff.new=green bold
color.status.added=yellow
color.status.changed=green
color.status.untracked=cyan
core.pager=less -FRSX
core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
alias.co=checkout
core.repositoryformatversion=0
core.filemode=false
core.bare=false
core.logallrefupdates=true
core.symlinks=false
core.ignorecase=true
core.hidedotfiles=dotGitOnly
core.autocrlf=false
remote.origin.url=<removed>
remote.origin.fetch=+refs/heads/*:refs/remotes/origin/*

Mise à jour: ajout de quelques fichiers d'exemple aléatoires. Ces fichiers ne sont que du texte brut, ce sont donc les plus faciles à inclure.

Les fichiers originaux se trouvent ici: https://gist.github.com/c3c5302430935155ef3d . Hexdumps indique clairement que les fichiers sont différents, mais je n'ai aucune idée de ce qui cause cela et comment le réparer.

Version HEAD:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740d  HTML.SafeObject.
0000010: 0a54 5950 453a 2062 6f6f 6c0d 0a56 4552  .TYPE: bool..VER
0000020: 5349 4f4e 3a20 332e 312e 310d 0a44 4546  SION: 3.1.1..DEF
0000030: 4155 4c54 3a20 6661 6c73 650d 0a2d 2d44  AULT: false..--D
0000040: 4553 4352 4950 5449 4f4e 2d2d 0d0a 3c70  ESCRIPTION--..<p
0000050: 3e0d 0a20 2020 2057 6865 7468 6572 206f  >..    Whether o
0000060: 7220 6e6f 7420 746f 2070 6572 6d69 7420  r not to permit 
0000070: 6f62 6a65 6374 2074 6167 7320 696e 2064  object tags in d
0000080: 6f63 756d 656e 7473 2c20 7769 7468 2061  ocuments, with a
0000090: 206e 756d 6265 7220 6f66 2065 7874 7261   number of extra
00000a0: 0d0a 2020 2020 7365 6375 7269 7479 2066  ..    security f
00000b0: 6561 7475 7265 7320 6164 6465 6420 746f  eatures added to
00000c0: 2070 7265 7665 6e74 2073 6372 6970 7420   prevent script 
00000d0: 6578 6563 7574 696f 6e2e 2054 6869 7320  execution. This 
00000e0: 6973 2073 696d 696c 6172 2074 6f0d 0a20  is similar to.. 
00000f0: 2020 2077 6861 7420 7765 6273 6974 6573     what websites
0000100: 206c 696b 6520 4d79 5370 6163 6520 646f   like MySpace do
0000110: 2074 6f20 6f62 6a65 6374 2074 6167 732e   to object tags.
0000120: 2020 596f 7520 7368 6f75 6c64 2061 6c73    You should als
0000130: 6f20 656e 6162 6c65 0d0a 2020 2020 254f  o enable..    %O
0000140: 7574 7075 742e 466c 6173 6843 6f6d 7061  utput.FlashCompa
0000150: 7420 696e 206f 7264 6572 2074 6f20 6765  t in order to ge
0000160: 6e65 7261 7465 2049 6e74 6572 6e65 7420  nerate Internet 
0000170: 4578 706c 6f72 6572 0d0a 2020 2020 636f  Explorer..    co
0000180: 6d70 6174 6962 696c 6974 7920 636f 6465  mpatibility code
0000190: 2066 6f72 2079 6f75 7220 6f62 6a65 6374   for your object
00001a0: 2074 6167 732e 0d0a 3c2f 703e 0d0a 2d2d   tags...</p>..--
00001b0: 2320 7669 6d3a 2065 7420 7377 3d34 2073  # vim: et sw=4 s
00001c0: 7473 3d34 0d0a                           ts=4..

Version copiée:

0000000: 4854 4d4c 2e53 6166 654f 626a 6563 740a  HTML.SafeObject.
0000010: 5459 5045 3a20 626f 6f6c 0a56 4552 5349  TYPE: bool.VERSI
0000020: 4f4e 3a20 332e 312e 310a 4445 4641 554c  ON: 3.1.1.DEFAUL
0000030: 543a 2066 616c 7365 0a2d 2d44 4553 4352  T: false.--DESCR
0000040: 4950 5449 4f4e 2d2d 0a3c 703e 0a20 2020  IPTION--.<p>.   
0000050: 2057 6865 7468 6572 206f 7220 6e6f 7420   Whether or not 
0000060: 746f 2070 6572 6d69 7420 6f62 6a65 6374  to permit object
0000070: 2074 6167 7320 696e 2064 6f63 756d 656e   tags in documen
0000080: 7473 2c20 7769 7468 2061 206e 756d 6265  ts, with a numbe
0000090: 7220 6f66 2065 7874 7261 0a20 2020 2073  r of extra.    s
00000a0: 6563 7572 6974 7920 6665 6174 7572 6573  ecurity features
00000b0: 2061 6464 6564 2074 6f20 7072 6576 656e   added to preven
00000c0: 7420 7363 7269 7074 2065 7865 6375 7469  t script executi
00000d0: 6f6e 2e20 5468 6973 2069 7320 7369 6d69  on. This is simi
00000e0: 6c61 7220 746f 0a20 2020 2077 6861 7420  lar to.    what 
00000f0: 7765 6273 6974 6573 206c 696b 6520 4d79  websites like My
0000100: 5370 6163 6520 646f 2074 6f20 6f62 6a65  Space do to obje
0000110: 6374 2074 6167 732e 2020 596f 7520 7368  ct tags.  You sh
0000120: 6f75 6c64 2061 6c73 6f20 656e 6162 6c65  ould also enable
0000130: 0a20 2020 2025 4f75 7470 7574 2e46 6c61  .    %Output.Fla
0000140: 7368 436f 6d70 6174 2069 6e20 6f72 6465  shCompat in orde
0000150: 7220 746f 2067 656e 6572 6174 6520 496e  r to generate In
0000160: 7465 726e 6574 2045 7870 6c6f 7265 720a  ternet Explorer.
0000170: 2020 2020 636f 6d70 6174 6962 696c 6974      compatibilit
0000180: 7920 636f 6465 2066 6f72 2079 6f75 7220  y code for your 
0000190: 6f62 6a65 6374 2074 6167 732e 0a3c 2f70  object tags..</p
00001a0: 3e0a 2d2d 2320 7669 6d3a 2065 7420 7377  >.--# vim: et sw
00001b0: 3d34 2073 7473 3d34 0a                   =4 sts=4.

Mise à jour: selon le commentaire sur cette question, le problème a été résolu:

C'est simple: le premier fichier a des fins de ligne CRLF (windows), le second LF (Unix). L' fileutil (disponible dans git \ usr \ bin) vous montrera que ( file a brépondra quelque chose comme a: ASCII text, with CRLF line terminators b: ASCII text)

Réponse originale ci-dessous:

Le diff que vous montrez fait pas une seule ligne différente. Pouvez-vous publier .git / config (ou mieux git config -l).

Certains espaces blancs peuvent être ignorés

Vous devriez essayer de désactiver core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

aussi

git show HEAD:myfile|md5sum
md5sum myfile

pourrait être utilisé pour vérifier que les fichiers sont en fait différents. L'utilisation de diff externe pourrait également fonctionner

git show HEAD:myfile > /tmp/myfile.HEAD

diff -u myfile /tmp/myfile.HEAD

# or if you prefer an interactive tool like e.g.:
vim -d myfile /tmp/myfile.HEAD

J'ai résolu ce problème en utilisant les étapes suivantes

1) Supprimez chaque fichier de l'index de Git.

git rm --cached -r .

2) Réécrivez l'index Git pour récupérer toutes les nouvelles fins de ligne.

git reset --hard

Notez que l'étape 2 peut supprimer vos modifications locales. La solution faisait partie des étapes décrites sur le site git https://help.github.com/articles/dealing-with-line-endings/

Avez-vous changé le mode des fichiers? Je l'ai fait sur ma machine et la machine de développement locale avait 777 données à tous les fichiers alors que le dépôt en avait 755 qui montraient chaque fichier comme modifié. Je l'ai fait git diffet cela a montré que l'ancien et le nouveau mode étaient différents. Si tel est le problème, vous pouvez facilement les ignorer par git config core.filemode false
Cheers

J'ai eu le même problème. après win-> lin copie j'ai tous les fichiers modifiés.
j'ai utilisé fromdos pour corriger les fins de ligne
, puis

git add -uv 

pour ajouter des modifications.
il a ajouté 3 fichiers (pas tous), que j'ai en fait modifiés. et après cela, l' état de git n'affiche que 3 fichiers modifiés. après git commit tout est ok avec git status

J'ai pu résoudre les problèmes sur la machine Windows en changeant core.autocrlf de false à core.autocrlf = input

git config core.autocrlf input

comme il est suggéré dans https://stackoverflow.com/a/1112313/52277

Dans mon cas, les fichiers sont apparus comme modifiés après la modification des autorisations de fichiers .

Pour que git ignore les modifications d'autorisation, procédez comme suit:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

Cependant, beaucoup de fichiers (sinon tous) apparaissent comme modifiés même si le contenu est exactement le même.

Avec git 2.8 (mars 2016), vous pourrez vérifier rapidement si ces changements sont liés à eol.

Voir commit a7630bd (16 janvier 2016) de Torsten Bögershausen ( tboegi) .
^{(Fusionné par Junio ​​C Hamano - gitster- dans commit 05f1539 , 03 févr.2016 )}

ls-files: ajouter des diagnostics eol

Lorsqu'il travaille dans un environnement multiplateforme, un utilisateur peut vouloir vérifier si les fichiers texte sont stockés normalisés dans le référentiel et si .gitattributes sont définis de manière appropriée.

Rendre possible de laisser Git afficher les fins de ligne dans l'index et dans l'arbre de travail et les attributs text / eol effectifs.

La fin de la ligne (" eolinfo") est affichée comme ceci:

"-text"        binary (or with bare CR) file
"none"         text file without any EOL
"lf"           text file with LF
"crlf"         text file with CRLF
"mixed"        text file with mixed line endings.

L'attribut text / eol effectif est l'un de ceux-ci:

"", "-text", "text", "text=auto", "text eol=lf", "text eol=crlf"

git ls-files --eol donne une sortie comme celle-ci:

i/none   w/none   attr/text=auto      t/t5100/empty
i/-text  w/-text  attr/-text          t/test-binary-2.png
i/lf     w/lf     attr/text eol=lf    t/t5100/rfc2047-info-0007
i/lf     w/crlf   attr/text eol=crlf  doit.bat
i/mixed  w/mixed  attr/               locale/XX.po

pour montrer quelle convention eol est utilisée dans les données de l'index ('i ') et de l'arbre de travail (' w'), et quel attribut est en vigueur, pour chaque chemin affiché .

Voici comment j'ai résolu le problème sous Linux pendant que je clonais un projet créé sous Windows:

sous linux pour que les choses fonctionnent correctement, vous devez avoir ce paramètre: core.autocrlf = input

voici comment le définir: git config --global core.autocrlf input

Puis clonez à nouveau le projet à partir de github.

La FAQ Git a une réponse qui pourrait être pertinente, même si je n'ai jamais rencontré cela auparavant:

Pourquoi git diff répertorie-t-il parfois un fichier sans changement?

git diff et les autres opérations git sont optimisées de sorte qu'il ne regarde même pas les fichiers dont l'état (taille, heure de modification, etc.) sur le disque et dans l'index de git sont différents. Cela rend git diff extrêmement rapide pour les petits changements. Si le fichier a été touché d'une manière ou d'une autre, git diff doit regarder le contenu et le comparer, ce qui est une opération beaucoup plus lente même s'il n'y a en fait aucun changement. git diff liste les fichiers pour rappeler qu'il n'est pas utilisé de manière optimale. L'exécution de l'état de git affichera non seulement l'état, mais mettra également à jour l'index avec l'état du disque de fichiers inchangés, ce qui rendra les opérations suivantes, non seulement diff, beaucoup plus rapides. Un cas typique qui fait que de nombreux fichiers sont répertoriés par diff est l'exécution de commandes d'édition en masse comme perl -pi -e '...'.

Que git statusmontre pour vous?

Après avoir copié mon référentiel local et ma copie de travail dans un autre dossier (sur Windows d'ailleurs), j'avais quatre fichiers qui continuaient à apparaître comme modifiés et j'ai essayé toutes les suggestions répertoriées dans les autres réponses. En fin de compte, ce qui a résolu le problème pour moi a été de supprimer la branche locale et de la télécharger à nouveau depuis la télécommande. Dans mon cas, je suppose que cela avait quelque chose à voir avec la copie d'un référentiel local plutôt que le clonage.

Donc, j'ai essayé à peu près tout ici et je veux apporter une solution supplémentaire qui a résolu tous mes problèmes. Mes problèmes ne concernaient pas les fins de ligne ou les autorisations réelles ou quelque chose comme ça. C'était parce que j'avais installé Cygwin et toute une foule de choses qui l'accompagnaient, qui à mon insu a également installé sa propre version de git. Je n'ai jamais remarqué cela, juste que j'avais des problèmes étranges avec les utilisateurs et les fichiers marqués comme modifiés (à cause des changements de perms).

Il s'avère que j'ai compris cela parce que je pensais que je devrais simplement mettre à jour Git vers la dernière version, ce que j'ai fait, mais l'exécution a git --versionrenvoyé l'ancien numéro de version. Après la recherche de pourquoi, j'ai trouvé la racine du répertoire cygwin bin dans le chemin de mon environnement, qui contenait un exécutable git, fonctionnant à l'ancien numéro de version. Allez comprendre.

C'était également difficile à trouver car TortoiseGit est installé. Mes outils de ligne de commande utiliseraient la version cygwin en raison des replis de chemin, et TortoiseGit a été configuré pour utiliser la version Windows, ce qui le rend encore plus déroutant.

J'espère que cela aide quelqu'un.

La seule entrée suspecte dans votre configuration me semble être core.ignorecase. Vous pouvez essayer de désactiver cela avec:

  git config --unset core.ignorecase

... et voyez si la sortie de git statusou git diffest différente.

Je viens de définir filemode = false dans .git / config et cela a fonctionné pour moi.

filemode = false

Pour moi, c'était parce que 2 machines virtuelles Linux étaient toutes deux mappées sur le même système de fichiers domestique. Une VM exécutait git-1.7.1 et l'autre exécutait git-2.14

La VM exécutant git-1.7.1 afficherait toujours 4 fichiers comme modifiés (même si le contenu et les fins de ligne étaient identiques).

Une fois que 'git status' était exécuté sur la VM exécutant g-2.14, les deux VM commenceraient à signaler le référentiel comme propre. 'git status' a des effets secondaires. Ce n'est pas une opération immuable. Et git-1.7.1 ne comprend pas le monde de la même manière que git-2 +.