Git klonundan hemen sonra değiştirilmiş olarak gösterilen dosyalar

Şu anda bir depoyla ilgili sorun yaşıyorum ve Git-fu'm genellikle iyi olsa da, bu sorunu çözemiyorum.

Bu depoyu klonladığımda, daha sonra cddepoya git statusdeğiştirildiğimde birkaç dosya gösterir. Not: Depoyu herhangi bir editörde veya başka bir şeyde açmadım.

Bu kılavuzu izlemeyi denedim: http://help.github.com/dealing-with-lineendings/ , ancak bu sorunumla hiç yardımcı olmadı.

git checkout -- .Birçok kez denedim , ama hiçbir şey yapmıyor gibi görünüyor.

Mac'liyim ve depoda alt modül yok.

Dosya sistemi Mac'te "Günlüklü HFS +" dosya sistemidir ve büyük / küçük harfe duyarlı değildir. Dosyalar bir satır ve her biri yaklaşık 79 KB (evet, doğru duydunuz), bu yüzden bakmak git diffözellikle yararlı değildir. git config --global core.trustctime falseHangi depo yardımcısıyla bilgisayara geri döndüğümde deneyeceğim yardımcı olabilecek şeyleri duydum .

Dosya sisteminin ayrıntılarını gerçeklerle değiştirdim! Ve git config --global core.trustctime falseçok iyi çalışmayan numarayı denedim .

Bir depoyu klonladıktan sonra Mac'te de aynı sorunu yaşadım. Tüm dosyaların değiştirildiğini varsayar.

Çalıştırdıktan sonra git config --global core.autocrlf input, tüm dosyalar değiştirildi olarak işaretleniyordu. Bir düzeltme aradıktan .gitattributessonra aşağıdaki dizine sahip ev dizininde dosyayla karşılaştım .

* text=auto

Ben yorum ve bundan sonra diğer klonlanmış depolar iyi çalışıyorlardı.

Anladım. Diğer tüm geliştiriciler Ubuntu'da (sanırım) ve bu nedenle büyük / küçük harfe duyarlı dosya sistemlerine sahipler. Ancak, (Mac'te olduğum gibi) yapmıyorum. Gerçekten de, kullandığım dosyalara baktığımda tüm dosyaların küçük ikizleri vardı git ls-tree HEAD <path>.

Bunlardan birini halledeceğim.

git config core.fileMode false

benim durumumda bu sorunu çözdü

https://git-scm.com/docs/git-config

TL; DR;

core.fileMode

False olursa, dizin ve çalışma ağacı arasındaki yürütülebilir bit farklılıkları yok sayılır; FAT gibi bozuk dosya sistemlerinde kullanışlıdır. Bkz. Git-update-index (1).

Git-clone (1) veya git-init (1), havuz oluşturulduğunda uygun olduğunda core.fileMode öğesini problayacak ve varsayılan olarak true olacaktır.

Windows kullandığınızı varsayıyorum. Bağlandığınız GitHub sayfasının ayrıntıları geriye dönük. Sorun, CR + LF satır sonlarının depoya zaten taahhüt edilmiş olması ve core.autocrlf değerinin true ya da input olarak ayarlanmış olması nedeniyle Git satır sonlarını LF'ye dönüştürmek istiyor.git status her dosyanın değiştiğini gösteriyor.

Bu yalnızca erişmek istediğiniz ancak herhangi bir katılımınız olmayan bir havuzsa, sorunu gerçekten çözmeden gizlemek için aşağıdaki komutu çalıştırabilirsiniz.

git config core.autocrlf false

Bu, aktif olarak dahil olacağınız ve üzerinde değişiklik yapabileceğiniz bir havuzsa. Depodaki tüm satır sonlarını CR + LF yerine LF kullanmak için değiştiren bir taahhüt yaparak sorunu düzeltmek ve daha sonra gelecekte tekrar olmasını önlemek için adımlar atabilirsiniz.

Aşağıdakiler doğrudan gitattributes man sayfasından alınır ve temiz bir çalışma dizininden önceden oluşturulmalıdır.

echo "* text=auto" >>.gitattributes
rm .git/index     # Remove the index to force Git to
git reset         # re-scan the working directory.
git status        # Show files that will be normalized.
git add -u
git add .gitattributes
git commit -m "Introduce end-of-line normalization"

Normalleştirilmemesi gereken herhangi bir dosya git statusgörünürse, çalıştırmadan önce metin özniteliklerini kaldırın git add -u.

manual.pdf      -text

Tersine, Git'in algılamadığı metin dosyalarında normalleştirme manuel olarak etkinleştirilebilir.

weirdchars.txt  text

Lütfen aşağıdaki komutları çalıştırın. Bu sorunu çözebilir.

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Visual Studio'da Git kullanıyorsanız .gitignore ve .gitattributes dosyalarını otomatik olarak oluşturabilirsiniz. Otomatik oluşturulan .getattributes dosyası aşağıdaki satıra sahiptir:

* text=auto

Bu satır dosyanın üst kısmına yakın. Biz sadece önüne # ekleyerek satır yorum yapmak gerekiyordu. Bunu yaptıktan sonra işler beklendiği gibi işledi.

Sorun , benim durumumda olduğu gibi farklı dosya izinlerinden de kaynaklanabilir :

Taze klonlanmış depo (Windows, Cygwin):

$ git ls-tree HEAD
100755 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Çıplak uzak depo (Linux):

$ git ls-tree HEAD
100644 blob 8099ea496a2c78d71125d79a05855f60ebf07904    testfile
   ↑↑↑

Bu "Neden" üzerine daha fazla yönlendirilmiş bir cevap eklemek istedim, çünkü bunu nasıl düzeltebileceğim konusunda zaten iyi bir cevap var.

Yani, bu soruna neden olan .gitattributesbir * text=autoayarı var.

Benim durumumda, GitHub'ın ana dalındaki dosyaların \r\nsonları vardı . \nBitişlerle check-in yapmak için depodaki ayarları çevirdim. Git'in neyi kontrol ettiğini bilmiyorum. Linux kutum ( \n) üzerine yerel sonları kontrol etmek gerekiyor , ancak sanırım \r\nsonları ile dosyayı teslim . Git şikayet ediyor, çünkü \r\ndepodaki teslim alınmış sonları görüyor ve \nayarları kontrol edeceği konusunda beni uyarıyor . Bu nedenle dosyalar "değiştirilecek" tir.

Şimdilik bu benim anlayışım.

Aynı sorun benim için. Uzak Git deposunda "textField.png" ve "textfield.png" gibi aynı ada sahip birkaç resim görebiliyordum, ancak yerel veri havuzumda göremedim. Sadece projenin kodunda kullanılmayan "textField.png" görebildim.

Görünüşe göre meslektaşlarımın çoğu Ubuntu'da ext4 dosya sistemi kullanıyorken APFS kullanan bir Mac'indeyim.

Sayesinde Sam Elliott 'ın cevabı, Çözüm oldukça basit. İlk önce Ubuntu'daki bir meslektaşımdan büyük dosya sürümleriyle gereksiz dosya sürümlerini silmesini istedim, ardından uzaktan kumandaya geçip gönderdim.

Sonra aşağıdakileri koştum:

# Remove everything from the index.
git rm --cached -r .

# Write both the index and working directory from git's database.
git reset --hard

Son olarak, her geliştiricinin bunun tekrar olmasını önlemek için Git yapılandırmasını değiştirmesi gerektiğine karar verdik:

# Local Git configuration
git config core.ignorecase = true

veya

# Global Git configuration
git config --global core.ignorecase = true

Ben de aynı problemi yaşadım. Ayrıca Mac ile. Bir Linux makinesindeki depoya baktığımda iki dosyam olduğunu fark ettim:

geoip.dat ve GeoIP.dat

Linux makinedeki kullanımdan kaldırılmış olanı kaldırdım ve depoyu tekrar Mac'e klonladım. Kopyalar varken havuzun kopyasını çekemedim, taahhüt edemedim, saklamamış veya çekemedim.

Ben de aynı problemi yaşadım. Benim durumumda depoyu klonladım ve bazı dosyalar hemen kayboldu.

Bunun nedeni, dosya yolu ve dosya adının Windows için çok uzun olmasıydı. Bu sorunu gidermek için, dosya yolunun uzunluğunu azaltmak amacıyla depoyu sabit disk sürücüsü köküne olabildiğince yakın klonlayın. Örneğin, C:\A\GitRepoyerine klonlayın C:\Users Documents\yyy\Desktop\GitRepo.

Şu dosyayı düzenleyin .git/config:

sudo gedit .git/config

Veya:

sudo vim .git/config

içindekiler

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = kharadepramod@bitbucket.org:DigitalPlumbing/unicorn-magento.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "master"]
    remote = origin
    merge = refs/heads/master

[branch "productapproval"]
    remote = origin
    merge = refs/heads/productapproval

Değiştir filemode=trueiçine filemode = false.

MacOS'un yeni sürümlerinde bunun nedeni işletim sisteminin güvenlik özelliğidir.

Üzerinde çalıştığım depoda dosya türü olarak * .app olan bir ikili dosya vardı.

Sadece bazı serileştirilmiş verilerdi, ancak macOS tüm * .app dosyalarını bir uygulama olarak ele alıyor ve bu dosya kullanıcı tarafından indirilmediğinden, sistem güvensiz kabul etti ve com.apple.quarantine dosyanın yürütülemediğinden emin olan dosya özniteliğini .

Ancak bu özniteliğin dosyada ayarlanması da dosyayı değiştiriyordu ve bu nedenle Git değişiklik kümesinde geri döndürülmeden ortaya çıktı.

Aynı sorunun olup olmadığını çalıştırarak kontrol edebilirsiniz $ xattr file.app.

Dosyayla çalışmak zorunda olmadığınız sürece çözüm oldukça basittir. Sadece eklemek *.app binaryadresinden Müşteri .gitattributes.

Yerel veri havuzumu başka bir klasöre kopyaladım ve bir grup değiştirilmiş dosya çıktı. Çözümüm şuydu: Değiştirilen dosyaları sakladım ve saklamayı sildim . Depo temiz oldu.

Git'in dosyalarıma (bu durumda .psd) metin olarak davrandığını gördüm. .Gitattributes dosyasında ikili bir tipe ayarlanması sorunu çözdü.

*.psd binary

Etkileşimli bir rebase yapmaya çalışıyordum, ancak bazı değiştirilmiş dosyalar olduğunu iddia etti, bu yüzden şu anda yapmama izin vermedi. Temiz bir depoya geri dönmek için her şeyi denedim , ama hiçbir şey işe yaramadı. Diğer cevapların hiçbiri işe yaramadı. Ama bu sonunda işe yaradı ...

git rm -rf the-folder-with-modified-stuff
git ci -m 'WAT'

Boom! Havuzu temizleyin. Sorun çözüldü. Sonra sadece benim yaptığım zaman son taahhüdü bırakmak zorunda kaldı rebase -ive sonunda her şey tekrar temiz oldu. Tuhaf!

Başka birine yardımcı olması durumunda, bu sorunun başka bir nedeni olabilir: Git'in farklı sürümleri. Bir Ubuntu 18.04 (Bionic Beaver) kutusunda Git'in varsayılan yüklü sürümünü kullanıyordum ve her şey iyi çalışıyordu, ancak Ubuntu 16.04'te Git'i kullanarak havuzu klonlamaya çalışırken, bazı dosyalar değiştirildiği gibi görünüyordu.

Buradaki diğer cevapların hiçbiri sorunumu çözmedi, ancak Git sürümlerini her iki sistemde de eşleştirmek için yükseltmek sorunu çözdü.