Lo stato Git mostra i file modificati anche se i contenuti sono gli stessi

Ho ricevuto una verifica git da qualcun altro e sto cercando di eseguire il commit delle modifiche non messe in scena nel repository locale. Tuttavia, molti file (se non tutti) vengono visualizzati come modificati anche se il contenuto è esattamente lo stesso.

Ho già impostato core.fileModesu false e impostato anche core.autocrlfsu false, senza successo.

Vale la pena ricordare che il repository Git che ho ricevuto proveniva da qualcuno che utilizzava Windows, mentre io uso Linux.

Cosa posso fare per confermare le modifiche effettive ?

EDIT: output di 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/*

Aggiornamento: aggiunti alcuni file di esempio casuali. Questi file sono solo in chiaro, quindi sono i più facili da includere.

I file originali si trovano qui: https://gist.github.com/c3c5302430935155ef3d . Gli esadecimali indicano sicuramente che i file sono diversi, ma non ho idea di cosa sia la causa e di come risolverlo.

Versione 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..

Versione copiata:

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.

Aggiornamento: come da commento a questa domanda, il problema è stato risolto:

È facile: il primo file ha i fine linea CRLF (windows), il secondo LF (Unix). L' fileutility (disponibile in git \ usr \ bin) ti mostrerà che ( file a brisponderà a qualcosa di simile a: ASCII text, with CRLF line terminators b: ASCII text)

Risposta originale di seguito:

Il diff che mostri non mostra una singola riga diversa. Puoi pubblicare .git / config (o meglio git config -l).

Potresti avere degli spazi bianchi ignorati attivati

Dovresti provare a disabilitare core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

anche

git show HEAD:myfile|md5sum
md5sum myfile

potrebbe essere utilizzato per verificare che i file siano effettivamente diversi. Anche l'utilizzo del diff esterno potrebbe funzionare

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

Ho risolto questo problema usando i seguenti stili

1) Rimuovi tutti i file dall'indice di Git.

git rm --cached -r .

2) Riscrivi l'indice Git per raccogliere tutte le nuove terminazioni di riga.

git reset --hard

Si noti che il passaggio 2 potrebbe rimuovere le modifiche locali. La soluzione faceva parte dei passaggi descritti sul sito git https://help.github.com/articles/dealing-with-line-endings/

Hai cambiato la modalità dei file? L'ho fatto sulla mia macchina e la macchina di sviluppo locale aveva 777 dati a tutti i file mentre il repository aveva 755 che mostrava tutti i file modificati. L'ho fatto git diffe ha mostrato che la vecchia modalità e la nuova modalità sono diverse. Se questo è il problema, puoi facilmente ignorarli con git config core.filemode false
Saluti

Ho avuto lo stesso problema. dopo win-> lin copy ho tutti i file modificati.
ho usato fromdos per correggere le terminazioni di linea
e poi

git add -uv 

per aggiungere modifiche.
ha aggiunto 3 file (non tutti), che ho effettivamente modificato. e dopo quello stato git mostra solo 3 file modificati. dopo git commit tutto è ok con lo stato git

Sono stato in grado di risolvere i problemi sulla macchina Windows cambiando core.autocrlf da false a core.autocrlf = input

git config core.autocrlf input

come suggerito in https://stackoverflow.com/a/1112313/52277

Nel mio caso i file sono stati visualizzati come modificati dopo aver modificato le autorizzazioni dei file .

Per fare in modo che git ignori le modifiche alle autorizzazioni, procedi come segue:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

Tuttavia, molti file (se non tutti) vengono visualizzati come modificati anche se il contenuto è esattamente lo stesso.

Con git 2.8 (marzo 2016), sarai in grado di verificare rapidamente se tali modifiche sono legate all'eol.

Vedi commit a7630bd (16 gennaio 2016) di Torsten Bögershausen ( tboegi) .
^{(Unito da Junio ​​C Hamano - gitster- in commit 05f1539 , 03 feb 2016)}

ls-files: aggiungi la diagnostica eol

Quando si lavora in un ambiente multipiattaforma, un utente potrebbe voler verificare se i file di testo sono archiviati normalizzati nel repository e se .gitattributessono impostati in modo appropriato.

Consentire a Git di mostrare le terminazioni di riga nell'indice e nella struttura di lavoro e gli attributi text / eol effettivi.

La fine della riga (" eolinfo") è mostrata in questo modo:

"-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'attributo text / eol efficace è uno di questi:

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

git ls-files --eol dà un output come questo:

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

per mostrare quale convenzione eol viene utilizzata nei dati nell'indice (' i') e nell'albero di lavoro (' w') e quale attributo è attivo, per ciascun percorso mostrato .

Ecco come ho risolto il problema su Linux mentre clonavo un progetto creato su Windows:

su Linux affinché le cose funzionino correttamente devi avere questa impostazione: core.autocrlf = input

ecco come impostarlo: git config --global core.autocrlf input

Quindi clonare nuovamente il progetto da github.

Le FAQ di Git hanno una risposta che potrebbe essere pertinente, anche se non l'ho mai trovato prima:

Perché a volte git diff elenca un file che non ha modifiche?

git diff e altre operazioni git sono ottimizzate in modo da non guardare nemmeno i file il cui stato (dimensioni, tempo di modifica ecc.) sul disco e nell'indice di git sono diversi. Questo rende git diff estremamente veloce per piccoli cambiamenti. Se il file è stato toccato in qualche modo, git diff deve esaminare il contenuto e confrontarlo, operazione molto più lenta anche quando in realtà non vi sono cambiamenti. git diff elenca i file come promemoria che non vengono utilizzati in modo ottimale. L'esecuzione di git status non solo mostrerà lo stato, ma aggiornerà anche l'indice con stato per il disco di file invariato, rendendo le operazioni successive, non solo diff, molto più veloci. Un caso tipico che fa sì che molti file vengano elencati da diff è l'esecuzione di comandi di modifica di massa come perl -pi -e '...'.

Cosa git statusti mostra?

Dopo aver copiato il mio repository locale e aver funzionato in un'altra cartella (su Windows), avevo quattro file che continuavano ad apparire come modificati e ho provato ogni suggerimento elencato nelle altre risposte. Alla fine, ciò che l'ha risolto per me è stato eliminare il ramo locale e scaricarlo di nuovo dal telecomando. Nel mio caso suppongo che avesse a che fare con la copia di un repository locale piuttosto che con la clonazione.

Quindi, ho provato praticamente tutto qui e voglio contribuire con un'altra soluzione che ha risolto tutti i miei problemi. I miei problemi non riguardavano le terminazioni di riga o le autorizzazioni effettive o cose del genere. Era perché avevo installato Cygwin e tutta una serie di cose che ne derivano, che a mia insaputa ho installato anche la sua versione di git. Non l'ho mai notato, solo che ho avuto strani problemi con gli utenti e i file sono stati contrassegnati come modificati (a causa di modifiche permanenti).

Si scopre che l'ho capito perché pensavo di dover aggiornare Git all'ultima versione, cosa che ho fatto, ma in esecuzione ha git --versionrestituito il vecchio numero di versione. Dopo la conseguente caccia al perché, ho trovato la radice della directory bin cygwin nel mio percorso di ambiente, che conteneva un eseguibile git, in esecuzione con il vecchio numero di versione. Vai a capire.

Anche questo è stato difficile da trovare perché ho installato TortoiseGit. I miei strumenti da riga di comando userebbero la versione cygwin a causa dei fallback dei percorsi e TortoiseGit è stato configurato per utilizzare la versione di Windows, rendendola ancora più confusa.

Spero che questo aiuti qualcuno.

L'unica voce sospetta nella tua configurazione mi sembra essere core.ignorecase. Puoi provare a disinserirlo con:

  git config --unset core.ignorecase

... e vedere se l'output da git statuso git diffè diverso.

Ho appena impostato filemode = false in .git / config e ha funzionato per me.

filemode = false

Per me è stato perché 2 VM Linux erano entrambe mappate sullo stesso file system di casa. Una VM eseguiva git-1.7.1 mentre l'altra eseguiva git-2.14

La VM che esegue git-1.7.1 mostrerebbe sempre 4 file come modificati (anche se i contenuti e le terminazioni di riga erano identici).

Una volta eseguito 'git status' sulla VM che esegue g-2.14, entrambe le VM inizierebbero a riportare il repository come pulito. 'git status' ha effetti collaterali. Non è un'operazione immutabile. E git-1.7.1 non capisce il mondo allo stesso modo di git-2 +.