Status Git menampilkan file yang diubah meskipun isinya sama

195

Saya menerima checkout git dari orang lain dan saya mencoba untuk melakukan perubahan yang tidak dipentaskan ke repositori lokal. Namun, banyak (jika tidak setiap) file yang muncul dimodifikasi meskipun isinya sama persis.

Saya sudah disetel core.fileModeke false dan juga setel core.autocrlfke false, tanpa hasil.

Layak disebutkan adalah bahwa repo Git yang saya terima adalah dari seseorang yang menggunakan Windows, sementara saya menggunakan Linux.

Apa yang bisa saya lakukan untuk melakukan perubahan yang sebenarnya ?

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

Perbarui: menambahkan beberapa file contoh acak. File-file ini hanya teks biasa, jadi yang paling mudah untuk dimasukkan.

File asli ada di sini: https://gist.github.com/c3c5302430935155ef3d . Hexdumps jelas menunjukkan bahwa file-file itu berbeda, tetapi saya tidak tahu apa yang menyebabkan ini, dan bagaimana cara memperbaikinya.

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

Versi yang disalin:

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.
Aron Rotteveel
sumber
1
Jika Anda tidak core.filemodedisetel, atau disetel ke true, apakah outputnya berbeda?
Mark Longair
Sedikit informasi penting lainnya yang akan membantu adalah keluaran darigit --version
Mark Longair
2
@AronRotteveel: Itu mudah: file pertama memiliki garis akhir CRLF (windows), LF kedua (Unix)
sehe
3
git 2.8 (Maret 2016) memperkenalkan git ls-files --eol, untuk dengan cepat melihat apakah eol terlibat. Lihat jawaban saya di bawah ini
VonC
Orang di windows dapat menjalankan git config --global core.autocrlf benar untuk menyelesaikan masalah ini.
Inyoka

Jawaban:

62

Pembaruan: sesuai komentar pada pertanyaan ini, masalah telah diselesaikan:

Itu mudah: file pertama memiliki ujung-ujung CRLF (windows), LF kedua (Unix). The fileutil (tersedia di git \ usr \ bin) akan menunjukkan bahwa ( file a bakan menjawab sesuatu seperti a: ASCII text, with CRLF line terminators b: ASCII text)

Jawaban asli di bawah:


Perbedaan yang Anda tampilkan tidak menunjukkan satu baris pun yang berbeda. Bisakah Anda memposting .git / config (atau lebih baik git config -l).

Anda mungkin mengaktifkan ruang kosong yang diabaikan

Anda harus mencoba menonaktifkan core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

juga

git show HEAD:myfile|md5sum
md5sum myfile

dapat digunakan untuk memverifikasi bahwa file-file tersebut sebenarnya berbeda. Menggunakan diff eksternal juga bisa bekerja

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
lihat
sumber
Yang aneh adalah bahwa md5sums untuk kedua file berbeda tetapi saya tidak dapat menemukan perbedaan spasi APAPUN . (Saya menganggap ini yang terjadi, tapi saya sederhana tidak melihatnya). Bantuan apapun akan diterima.
Aron Rotteveel
Cukup unggah contoh di suatu tempat (gist.github.com akan sesuai untuk ini). Saya menganggap itu dengan baris baru pada baris terakhir, tanda byte-order-tanda , atau pengkodean UTF8 non-kanonik secara umum. Anda selalu dapat melihat xxdatau bdiffmelakukan diff biner juga
sehe
terima kasih atas tipnya. xddbaru bagi saya. Alat hebat! Saya memperbarui posting saya dengan sebuah contoh.
Aron Rotteveel
1
@AronRotteveel: Itu mudah: file pertama memiliki garis akhir CRLF (windows), LF kedua (Unix). Mengedit The fileutil akan menunjukkan bahwa ( file a bakan menjawab sesuatu seperti a: ASCII text, with CRLF line terminators b: ASCII text)
sehe
bukankah seharusnya itu benar-benar ditampilkan sebagai ^ M di VIM? (Saya tidak melihatnya). Jelas, saya percaya Anda, tetapi saya benar-benar tertarik pada bagaimana Anda benar-benar memperhatikan ini :)
Aron Rotteveel
135

Saya telah mengatasi masalah ini menggunakan stpes berikut

1) Hapus setiap file dari indeks Git.

git rm --cached -r .

2) Tulis ulang indeks Git untuk mengambil semua akhiran baris baru.

git reset --hard

Perhatikan bahwa langkah 2 dapat menghapus perubahan lokal Anda. Solusi adalah bagian dari langkah-langkah yang dijelaskan di situs git https://help.github.com/articles/dealing-with-line-endings/

Jacek Szybisz
sumber
Dalam kasus saya, saya telah membuat banyak catatan untuk beberapa file, lalu menyalin repo tanpa folder .git ke komputer baru. Ketika saya menyadari bahwa saya kehilangan paket .git saya, sudah terlambat untuk kembali dan mengambilnya. Jadi saya: 1. Check out salinan baru dari seluruh repo 2. Diganti file vanili dengan file dengan perubahan saya 3. Ran satu langkah dalam posting OP: git rm --cached -r .4. ini dipentaskan perubahan saya (dan file lain yang harus digantikan ) jadi saya unstaged mereka. Pada titik ini repo saya kembali normal.
cody
2
Cemerlang. Terima kasih untuk ini.
rupi
6
Harus hati-hati karena Anda akan kehilangan perubahan lain jika Anda melakukannya.
Mohy Eldeen
Saya mengalami masalah ini setelah menyalin & menempel folder repo saya dari Windows ke Ubuntu. Tidak ada perubahan lokal, tetapi karena suatu alasan, git berpikir setiap file telah berubah. Solusi ini menyelesaikan masalah ini.
Linek
88

Sudahkah Anda mengubah mode file? Saya melakukannya pada mesin saya dan mesin dev lokal telah 777 diberikan kepada semua file sedangkan repo memiliki 755 yang menunjukkan setiap file sebagai dimodifikasi. Saya lakukan git diffdan itu menunjukkan mode lama dan mode baru berbeda. Jika itu masalahnya maka Anda dapat dengan mudah mengabaikannya dengan git config core.filemode false
Ceria

itsandy
sumber
2
Menggunakan Windows 10 lxss (yaitu Ubuntu Bash) dengan repo di sistem file Windows dengan git di Linux, saya pikir itu adalah masalah akhir baris. Bahkan tidak menganggap itu bisa menjadi cara mode file berbeda juga.
Matt L
Ini bekerja untuk saya ketika saya mengubah O / S lokal saya dari Ubuntu ke Windows. Cheers
Mark Bucknell
@MattL dan itsandy Saya biasanya mengembangkan pada Win 10 dengan Git Bash, tapi hari ini saya di Mac dan melihat bahwa git berpikir .gitignorefile telah berubah ketika mereka belum. Di Mac ini, git config core.filemodemerespons dengan true. Saya mengubahnya menjadi false, tetapi itu tidak membantu.
Ryan
43

Saya memiliki masalah yang sama. setelah win-> lin copy saya sudah mendapatkan semua file dimodifikasi.
Saya menggunakan fromdos untuk memperbaiki akhir baris
dan kemudian

git add -uv 

untuk menambahkan perubahan.
ia menambahkan 3 file (tidak semuanya), yang sebenarnya saya modifikasi. dan setelah itu status git hanya menampilkan 3 file yang dimodifikasi. setelah git komit semuanya ok dengan status git

Demo_S
sumber
2
Terima kasih, ini yang saya butuhkan. Saya menggunakan saran @ sehe membandingkan md5sum's untuk memverifikasi file yang identik (dalam kasus saya). Setelah itu menggunakan flag -u dengan benar memfilter file-file itu tanpa perbedaan yang nyata dari yang dengan perubahan.
STW
Terima kasih, ini sangat membantu. Saya memiliki masalah ini setelah melakukan npm idi root proyek saya. Entah bagaimana, banyak file mendapatkan akhiran baris yang berbeda, yang menyebabkan masalah ini.
Server Khalilov
inilah yang saya harapkan ... perubahan yang telah dilakukan tetap dan sisanya dibatalkan
Deepak
28

Saya dapat memperbaiki masalah pada mesin Windows dengan mengubah core.autocrlf dari false ke core.autocrlf = input

git config core.autocrlf input

seperti yang disarankan di https://stackoverflow.com/a/1112313/52277

Michael Freidgeim
sumber
25

Dalam kasus saya file-file tersebut muncul sebagai diubah setelah mengubah izin file .

Untuk membuat git abaikan perubahan izin, lakukan hal berikut:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false
Sakis
sumber
1
Jawaban Anda menghemat banyak waktu. Terima kasih!
Pavel_K
Setelah melakukan ini, saya sarankan menyimpan / menentukan perubahan yang diinginkan , mengatur ulang / memeriksa file yang telah memiliki izin mereka berubah, dan kemudian mengaktifkan kembali core.filemode. :)
XtraSimplicity
Saya mengalami masalah ini setelah menyalin file dari satu laptop ke laptop lain. Perbaikan Anda menyimpannya. Terima kasih!
Sam
23

Namun, banyak (jika tidak setiap) file yang muncul dimodifikasi meskipun isinya sama persis.

Dengan git 2.8 (Maret 2016), Anda akan dapat dengan cepat memeriksa apakah perubahan itu terkait dengan eol.

Lihat komit a7630bd (16 Jan 2016) oleh Torsten Bögershausen ( tboegi) .
(Digabung oleh Junio ​​C Hamano - gitster- dalam komit 05f1539 , 03 Feb 2016)

ls-files: tambahkan diagnostik eol

Ketika bekerja di lingkungan lintas platform, pengguna mungkin ingin memeriksa apakah file teks disimpan dinormalisasi di repositori dan jika .gitattributesdiatur dengan tepat.

Buatlah memungkinkan untuk membiarkan Git menunjukkan akhir baris dalam indeks dan di pohon kerja dan atribut teks / eol yang efektif.

Akhir baris (" eolinfo") ditampilkan seperti ini:

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

Atribut teks / eol yang efektif adalah salah satunya:

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

git ls-files --eol memberikan output seperti ini:

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

untuk menunjukkan konvensi eol apa yang digunakan dalam data dalam indeks (' i'), dan di pohon kerja (' w'), dan atribut apa yang berlaku, untuk setiap jalur yang ditampilkan .

VONC
sumber
Meskipun ini menunjukkan masalah, itu tidak memperbaikinya.
Greeso
7

Inilah cara saya memperbaiki masalah di Linux saat saya mengkloning proyek yang dibuat pada Windows:

di linux agar hal-hal berfungsi dengan benar, Anda harus memiliki pengaturan ini: core.autocrlf = input

ini adalah cara mengaturnya: git config --global core.autocrlf input

Kemudian klon proyek lagi dari github.

pencari kebenaran
sumber
Ini bekerja untuk saya dalam skenario di mana saya menggunakan Visual Studio pada Windows, tetapi saya melakukan komit dan pemeriksaan tambahan di WSL pada baris perintah. Pada baris perintah, setiap file ditampilkan berubah, tetapi di Visual Studio, hanya beberapa file yang berubah. Saya menambahkan input autoclrf = dalam file .gitconfig saya dan langsung memperbaikinya. Terima kasih!
Big Data Brian
5

The Git FAQ memiliki jawaban yang mungkin relevan, meskipun saya belum pernah datang di ini sebelumnya:

Mengapa git diff terkadang membuat daftar file yang tidak memiliki perubahan?

git diff dan operasi git lainnya dioptimalkan sehingga bahkan tidak melihat file yang statusnya (ukuran, waktu modifikasi dll) pada disk dan dalam indeks git berbeda. Ini membuat git diff sangat cepat untuk perubahan kecil. Jika file telah disentuh entah bagaimana, git diff harus melihat konten dan membandingkannya yang merupakan operasi yang jauh lebih lambat bahkan ketika sebenarnya tidak ada perubahan. git diff mendaftar file sebagai pengingat bahwa itu tidak digunakan secara optimal. Menjalankan status git tidak hanya akan menampilkan status, tetapi juga akan memperbarui indeks dengan status untuk disk file yang tidak berubah, membuat operasi selanjutnya, tidak hanya berbeda, jauh lebih cepat. Kasus khas yang menyebabkan banyak file didaftarkan oleh diff adalah menjalankan perintah pengeditan massal seperti perl -pi -e '...'.

Apa yang git statusditunjukkan untuk Anda?

Mark Longair
sumber
git statushanya menunjukkan daftar besar file di bagian yang dimodifikasi.
Aron Rotteveel
@Ron: berdasarkan petunjuk itu saya akan mengatakan: 85% mengatakan konversi
lineend
4
Wow. Pengingat betapa tidak dapat dipahami beberapa dokumen resmi git.
Mars
2

Setelah menyalin repositori lokal saya dan bekerja menyalin ke folder lain (pada Windows dengan cara), saya punya empat file yang terus muncul sebagai diubah dan mencoba setiap saran yang tercantum dalam jawaban lain. Pada akhirnya yang diperbaiki untuk saya adalah menghapus cabang lokal dan mengunduhnya lagi dari jarak jauh. Dalam kasus saya, saya kira itu ada hubungannya dengan menyalin repositori lokal daripada kloning.

Nate Cook
sumber
2

Jadi, saya mencoba hampir semuanya di sini dan ingin berkontribusi satu solusi lagi yang memperbaiki semua masalah saya. Masalah saya bukan pada akhiran baris atau izin aktual atau semacamnya. Itu karena saya telah menginstal Cygwin dan seluruh banyak hal yang datang dengan itu, yang tanpa sepengetahuan saya juga menginstal versi git sendiri. Saya tidak pernah memperhatikan ini, hanya saja saya mengalami masalah aneh dengan pengguna dan file ditandai sebagai diubah (karena perubahan perms).

Ternyata saya menemukan ini karena saya pikir saya harus memperbarui Git ke versi terbaru, yang saya lakukan, tetapi menjalankan git --versionmengembalikan nomor versi lama. Setelah perburuan berikutnya untuk alasannya, saya menemukan root direktori cygwin bin di jalur lingkungan saya, yang berisi executable git, berjalan pada nomor versi lama. Sosok pergi.

Ini juga sulit ditemukan karena saya sudah menginstal TortoiseGit. Alat baris perintah saya akan menggunakan versi cygwin karena path fallbacks, dan TortoiseGit dikonfigurasi untuk menggunakan versi windows, menjadikannya lebih membingungkan.

Semoga ini bisa membantu seseorang.

dudewad
sumber
1
Tangkapan yang bagus. +1. Itu sebabnya saya selalu mengatur PATH saya sendiri, seperti di stackoverflow.com/a/44351065/6309
VonC
Saya sering akan membiarkan installer mengatur PATH tetapi kemudian memeriksanya secara manual, yang saya lakukan di sini. Instalasi saya sebelumnya memiliki git 2.4.x (x86) dan saya menginstal git 2.13.x (x64). Anda dapat membayangkan kebingungan saya ketika saya menghapus referensi jalur x86 dan masih mendapatkan 2,4 !! Saat itulah aku melihat direktori bin cygwin dan itu sepertinya tempat logis berikutnya untuk mencari. Jadi pengaturan FWIW atau bahkan memeriksa PATH Anda secara visual mungkin tidak menyelesaikan ini jika direktori Cygwin terdaftar terlebih dahulu!
dudewad
1

Satu-satunya entri yang dicurigai dalam konfigurasi Anda adalah saya core.ignorecase. Anda dapat mencoba membatalkannya dengan:

  git config --unset core.ignorecase

... dan lihat apakah output dari git statusatau git diffberbeda.

Mark Longair
sumber
1

Saya baru saja mengatur filemode = false di .git / config dan berhasil bagi saya.

filemode = false
Felipe Santa
sumber
0

Bagi saya itu karena 2 VM linux dipetakan ke sistem file rumah yang sama. Satu VM menjalankan git-1.7.1 dan yang lainnya menjalankan git-2.14

VM yang menjalankan git-1.7.1 akan selalu menampilkan 4 file yang telah diubah (walaupun konten dan akhir barisnya sama)

Setelah 'git status' dijalankan pada VM yang menjalankan g-2.14, maka kedua VM akan mulai melaporkan repositori sebagai bersih. 'git status' memiliki efek samping. Ini bukan operasi abadi. Dan git-1.7.1 tidak memahami dunia dengan cara yang sama seperti yang dilakukan git-2 +.

William
sumber