Git durumu, içerikler aynı olsa bile dosyaları değiştirilmiş olarak gösterir


195

Birinden bir git check-out aldım ve yerel depodaki unstaged değişiklikleri yapmaya çalışıyorum. Bununla birlikte, içerikler tamamen aynı olsa bile bir çok (her biri değilse) dosya değiştirilmiş olarak görünür .

Zaten core.fileModeyanlış olarak ayarladım core.autocrlfve başarılı olmadan da yanlış olarak ayarladım .

Bahsetmeye değer, aldığım Git repo'nun Windows kullanırken birinden geldiği.

Gerçek değişiklikleri yapmak için ne yapabilirim ?

EDIT: çıktı 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/*

Güncelleme: bazı rastgele örnek dosyalar ekledi. Bu dosyalar sadece düz metindir, bu nedenle dahil edilmesi en kolay olanlarıdır.

Orijinal dosyalar burada bulunur: https://gist.github.com/c3c5302430935155ef3d . Hexdumps kesinlikle dosyaların farklı olduğunu gösterir, ama buna neden olan ve nasıl düzeltileceği hakkında hiçbir fikrim yok.

KAFA sürümü:

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

Kopyalanan sürüm:

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.

1
Eğer varsa core.filemodetanımsız ya seti için trueçıkış farkı nedir?
Mark Longair

Yardımcı olacak diğer önemli bilgi ise çıktıgit --version
Mark Longair

2
@AronRotteveel: Bu kolay: ilk dosya CRLF satır sonlarına (windows), ikinci LF'ye (Unix) sahiptir
14'te sehe

3
git 2.8 (Mart 2016) git ls-files --eol, eol'un dahil olup olmadığını hızlı bir şekilde görmek için tanıtır . Aşağıdaki cevabımı
VonC

Windows'daki kişi bu sorunu çözmek için git config --global core.autocrlf true komutunu çalıştırabilir .
Inyoka

Yanıtlar:


62

Güncelleme: bu soruya yapılan yoruma göre, sorun çözüldü:

Bu kolay: ilk dosya CRLF satır sonlarına (windows), ikinci LF'ye (Unix) sahiptir. file(Git \ usr \ bin mevcuttur) util (yani size gösterecektir file a bgibi bir şey cevap verecektir a: ASCII text, with CRLF line terminators b: ASCII text)

Aşağıdaki orijinal cevap:


Göstermek diff yok değil tek farklı satırı gösterilir. .Git / config (veya daha iyisi git config -l) yayınlayabilir misiniz?

Bazı boşlukları yok saymayı etkinleştirmiş olabilirsiniz

Devre dışı bırakmaya çalışmalısınız core.whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol;

Ayrıca

git show HEAD:myfile|md5sum
md5sum myfile

aslında dosyaların farklı olduğunu doğrulamak için kullanılabilir. Harici fark kullanmak da işe yarayabilir

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

Garip bir şey, her iki dosya için md5sums farklı ama herhangi bir boşluk farkı bulamıyorum olmasıdır . (Ben böyle olduğunu varsayıyorum, ama basit görmüyorum). Her türlü yardıma açığım.
Aron Rotteveel

Sadece bir yere bir örnek yükleyin (gist.github.com bunun için uygun olacaktır). Genelde son satırda yeni satır, bayt sırası işareti veya standart olmayan UTF8 kodlamaları olduğunu varsayıyorum . Her zaman ikili xxdbdiff
diffs'lara

Bahşiş için teşekkürler. xddbenim için yeniydi. Harika bir araç! Yazımı bir örnekle güncelledim.
Aron Rotteveel

1
@AronRotteveel: Bu kolay: ilk dosya CRLF satır sonlarına (windows), ikinci LF'ye (Unix) sahiptir. Düzenlemefile util (yani size gösterecektir file a bgibi bir şey cevap verecektir a: ASCII text, with CRLF line terminators b: ASCII text)
sehe

bunlar VIM'de ^ M olarak gösterilmemelidir? (Görmüyorum). Açıkçası, sana inanıyorum, ama bunu gerçekten nasıl fark
ettiğinle

135

Aşağıdaki sorunları kullanarak bu sorunu çözdüm

1) Her dosyayı Git'in dizininden kaldırın.

git rm --cached -r .

2) Tüm yeni satır sonlarını almak için Git dizinini yeniden yazın.

git reset --hard

2. adımın yerel değişikliklerinizi kaldırabileceğini unutmayın. Çözüm git sitesinde açıklanan adımların bir parçasıydı https://help.github.com/articles/dealing-with-line-endings/


Benim durumumda, bazı dosyalara bir sürü not yazdım, sonra .git klasörü olmadan repoyu yeni bir bilgisayara kopyaladım. .Git paketimi kaçırdığımı fark ettiğimde, geri dönüp geri almak için çok geçti. Bu yüzden ben: 1. Tüm repo'nun yeni bir kopyasını kontrol ettim 2. Vanilya dosyalarını değişikliklerimle değiştirdiler 3. OP'nin gönderisinde birinci adımı çalıştırdım: git rm --cached -r .4. Bu değişikliklerimi (ve değiştirilen diğer dosyaları) ) bu yüzden onları işaretsiz bıraktım. Bu noktada depom normale döndü.
cody

2
Parlak. Bunun için teşekkürler.
rupi

6
Dikkat etmelisin çünkü eğer yaparsan diğer değişiklikleri kaybedeceksin.
Mohy Eldeen

Kopyalama ve repo klasörü Windows Ubuntu yapıştırma sonra bu sorunu vardı. Yerel değişiklik olmadı, ama bir sebepten dolayı git her dosyanın değiştiğini düşündü. Bu çözüm bu sorunu çözdü.
Linek

88

Dosyaların modunu değiştirdiniz mi? Makinemde yaptım ve yerel dev makinesi 777 tüm dosyalara verildi, repo 755 her dosyayı değiştirilmiş olarak gösterdi. Ben yaptım git diffve eski modu ve yeni mod farklıdır gösterdi. Sorun buysa, git config core.filemode false
Cheers tarafından kolayca görmezden gelebilirsiniz.


2
Linux'ta git ile Windows dosya sisteminde bir repo ile Windows 10 lxss (yani Ubuntu Bash) kullanarak, bunun bir satır sonu sorunu olduğunu düşünmüştüm. Hatta dosya modlarının da farklı olabileceğini düşünmemişti.
Matt L

Yerel O / S cihazımı Ubuntu'dan Windows'a değiştirdiğimde bu benim için çalıştı. Şerefe
Mark Bucknell

@MattL ve itsandy Genellikle Git Bash ile Win 10 üzerinde geliştiriyorum, ancak bugün Mac'liyim ve git .gitignoredosyalarının değişmediklerinde değiştiğini düşünüyor . Bu Mac'te ile git config core.filemodeyanıt verir true. Bunu ben değiştirdim false, ama bu işe yaramadı.
Ryan

43

aynı problemi yaşadım. win-> lin kopyadan sonra tüm dosyaları değiştirdim. Satır sonlarını düzeltmek için fromdos
kullandım ve sonra

git add -uv 

değişiklikler eklemek için.
i aslında değiştirilmiş 3 dosya (hepsi değil) ekledi. ve sonra git durumu yalnızca 3 değiştirilmiş dosyayı gösterir. git taahhütten sonra git durumu ile her şey yolunda


2
Teşekkürler, ihtiyacım olan buydu. @ Sehe'nin dosyaları aynı olduğunu doğrulamak için md5sum's karşılaştırma önerisini kullandım (benim durumumda). Bundan sonra -u bayrağını kullanmak, değişiklik yapanlardan gerçek farkı olmayan bu dosyaları doğru şekilde filtreledi.
STW

Teşekkürler, yardımcı oldu. Bu problemi projemin npm ikökünden yaptıktan sonra yaşadım . Her nasılsa, birçok dosya bu sorunu yaratan farklı bir satır sonları alıyordu.
Sunucu Khalilov

beklediğim budur ... yapılan değişiklikler kalır ve geri kalanı geri
Deepak


25

Benim durumumda , dosyalar izinler değiştirildikten sonra dosyalar değiştirilmiş olarak göründü .

Git izin değişikliklerini yoksaymak için aşağıdakileri yapın:

# For the current repository
git config core.filemode false   

# Globally
git config --global core.filemode false

1
Cevabınız bana çok zaman kazandırdı. Teşekkürler!
Pavel_K

Bunu yaptıktan sonra, istenen değişiklikleri saklamanızı / hazırlamanızı, izinleri değiştirilen dosyaları sıfırlamanızı / kontrol etmenizi ve ardından yeniden etkinleştirmenizi öneririm core.filemode. :)
XtraSimplicity

Dosyaları bir dizüstü bilgisayardan diğerine kopyaladıktan sonra bu sorunu yaşadım. Senin sabitin kurtardı. Teşekkürler!
Sam

23

Bununla birlikte, içerikler tamamen aynı olsa bile çok (her biri değilse) dosya değiştirilmiş olarak görünür.

Git 2.8 (Mart 2016) ile, bu değişikliklerin eol ile ilişkili olup olmadığını hızlı bir şekilde kontrol edebilirsiniz.

Bakınız Torsten Bögershausen ( ) tarafından a7630bd (16 Ocak 2016 ) . (Göre Birleştirilmiş - Junio Cı Hamano - içinde 05f1539 tamamlama 2016, 03 Şubat)tboegi
gitster

ls-files: eol teşhisi ekle

Platformlar arası bir ortamda çalışırken, kullanıcı metin dosyalarının depoda normalleştirilmiş olarak depolanıp depolanmadığını ve .gitattributesuygun şekilde ayarlanıp ayarlanmadığını kontrol etmek isteyebilir .

Git'in dizin ve çalışma ağacındaki satır sonlarını ve etkili metin / eol niteliklerini göstermesine izin verin.

Satırın sonu (" eolinfo") şu şekilde gösterilir:

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

Etkili metin / eol özelliği şunlardan biridir:

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

git ls-files --eol şöyle bir çıktı verir:

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

gösterilen her yol için dizinde (' i') ve çalışma ağacında (' w') verilerde hangi eol kuralının kullanıldığını ve hangi özniteliğin geçerli olduğunu göstermek için .


Bu sorunu göstermesine rağmen, sorunu çözmez.
Greeso

7

Windows'da oluşturulan bir projeyi klonlarken Linux'ta sorunu nasıl çözdüm:

şeylerin düzgün çalışması için linux'da şu ayara sahip olmanız gerekir: core.autocrlf = input

nasıl ayarlayacağınız: git config --global core.autocrlf input

Sonra projeyi tekrar github'dan klonlayın.


Bu Windows için Visual Studio kullandığım bir senaryoda benim için çalıştı, ancak komut satırında WSL'de taahhütler ve ek denetimler yapıyorum. Komut satırında, her dosya değişti olarak görüntülendi, ancak Visual Studio'da yalnızca birkaç dosya değişti. .Gitconfig dosyama autoclrf = input ekledim ve anında düzeltti. Teşekkür ederim!
Büyük Veri Brian

5

Git SSS Bunu daha önce rastlamak hiç rağmen, alakalı olabilecek bir cevabı var:

Git diff neden bazen değişiklik olmayan bir dosyayı listeliyor?

git diff ve diğer git işlemleri optimize edilmiştir, böylece diskteki ve git dizinindeki durumu (boyut, değiştirme zamanı vb.) farklı olan dosyalara bile bakmaz. Bu, git farkını küçük değişiklikler için son derece hızlı yapar. Dosyaya bir şekilde dokunulduysa, git diff'in içeriğine bakması ve karşılaştırması gerekir, bu aslında hiçbir değişiklik olmasa bile çok daha yavaş bir işlemdir. git diff, dosyaları en iyi şekilde kullanılmadığını hatırlatmak için listeler. Git durumunu çalıştırmak sadece durumu göstermekle kalmaz, aynı zamanda dizini değişmeyen dosyalar için durumla günceller, disk sonraki işlemleri yapar, sadece farklı değil, çok daha hızlıdır. Diff tarafından birçok dosyanın listelenmesine neden olan tipik bir durum, perl -pi -e '...' gibi toplu düzenleme komutlarını çalıştırmaktır.

git statusSize ne gösteriyor?


git statussadece değiştirilmiş bölümdeki dosyaların büyük bir listesini gösterir.
Aron Rotteveel

@Aron: söyleyeceğim ipucuna dayanarak:% 85 hat sonu dönüşümü diyor
9'da

4
Vay. Bazı resmi git belgelerinin ne kadar anlaşılmaz olduğuna dair bir hatırlatma.
Mars

2

Yerel veri havuzumu ve çalışma kopyamı başka bir klasöre kopyaladıktan sonra (bu arada Windows'ta), değişmiş olarak görünmeye devam eden ve diğer yanıtlarda listelenen her öneriyi deneyen dört dosyam vardı. Sonunda benim için sabit olan şey, yerel şubeyi silmek ve uzaktan kumandadan tekrar indirmekti. Benim durumumda, klonlama yerine yerel bir deponun kopyalanmasıyla ilgili bir şey olduğunu düşünüyorum.


2

Bu yüzden, burada her şeyi denedim ve tüm sorunlarımı çözen bir çözüme daha katkıda bulunmak istiyorum. Sorunlarım satır sonları, gerçek izinler veya bunun gibi bir şeyle ilgili değildi. Çünkü Cygwin'i ve bununla birlikte gelen tüm şeyleri kurmuştum, ki bana göre bilmediğim kendi git sürümünü de kurdum. Bunu fark etmedim, sadece kullanıcılarla ve dosyalarla değiştirildi (izin değişiklikleri nedeniyle) ile garip sorunlar yaşıyorum.

Bunu anladım, çünkü Git'i en son sürüme güncellemem gerektiğini düşündüm, ancak çalışan git --versioneski sürüm numarasını döndürdü. Bunu izleyen avdan sonra, eski sürüm numarasında çalışan bir çalıştırılabilir dosyası içeren ortam yolumda cygwin bin dizin kökünü buldum. Git şekil.

TortoiseGit yüklü olduğundan bu da bulmak zordu. Komut satırı araçlarım, yolun geri dönüşleri nedeniyle cygwin sürümünü kullanacaktı ve TortoiseGit, Windows sürümünü kullanacak şekilde yapılandırıldı ve bu da daha da kafa karıştırıcı hale geldi.

Umarım bu birine yardımcı olur.


1
İyi yakalama. +1. Bu yüzden PATH'mi her zaman kendim ayarladım, stackoverflow.com/a/44351065/6309
VonC

Bir yükleyicinin PATH'ı ayarlamasına izin vereceğim, ancak burada yaptığım manuel olarak kontrol edeceğim. Önceki yüklememde git 2.4.x (x86) vardı ve git 2.13.x (x64) sürümünü yükledim. X86 yol referansını kaldırdığımda ve hala 2.4'üm olduğunda karışıklığımı hayal edebilirsiniz! O zaman cygwin'in bin dizinini gördüm ve bakmak için bir sonraki mantıklı yer gibi görünüyordu. Bu nedenle, Cygwin bin dizini ilk önce listeleniyorsa FWIW ayarı veya hatta PATH'inizi görsel olarak kontrol etmek bunu çözmeyebilir!
dudewad

1

Yapılandırmanızdaki tek şüpheli giriş bana benziyor core.ignorecase. Bunu şununla ayarlamayı deneyebilirsiniz:

  git config --unset core.ignorecase

Çıktısı eğer ... ve bakın git statusveya git difffarklı.


1

Ben sadece .git / config filemode = false ayarladım ve benim için çalıştı.

filemode = false

0

Benim için 2 linux VM'nin ikisi de aynı ev dosya sistemine eşlenmişti. Bir VM git-1.7.1 çalıştırırken diğeri git-2.14 çalıştırıyordu

Git-1.7.1 çalıştıran sanal makine her zaman 4 dosyayı değiştirilmiş olarak gösterir (içerik ve satır sonlarının aynı olduğunu düşünmüş olsa bile).

'Git durumu' g-2.14 çalıştıran VM'de çalıştırıldıktan sonra, her iki VM de havuzu temiz olarak raporlamaya başlar. 'git status' yan etkilere sahiptir. Bu değişmez bir işlem değildir. Git-1.7.1, dünyayı git-2 + ile aynı şekilde anlamıyor.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.