File yang ditampilkan telah dimodifikasi secara langsung setelah klon Git

Saya mengalami masalah dengan repositori saat ini, dan meskipun Git-fu saya biasanya bagus, saya sepertinya tidak bisa menyelesaikan masalah ini.

Ketika saya mengkloning repositori ini, kemudian cdke repositori, git statusmenunjukkan beberapa file yang berubah. Catatan: Saya belum membuka repositori dalam editor apa pun atau apa pun.

Saya mencoba mengikuti panduan ini: http://help.github.com/dealing-with-lineendings/ , tetapi ini tidak membantu sama sekali dengan masalah saya.

Saya sudah mencoba git checkout -- .berkali-kali, tetapi sepertinya tidak melakukan apa-apa.

Saya menggunakan Mac, dan tidak ada submodul dalam repositori itu sendiri.

Sistem file adalah sistem file "Jurnal HFS +" pada Mac dan tidak peka huruf besar-kecil. File-file ini satu-baris dan masing-masing sekitar 79 KB (ya, Anda dengar benar), jadi melihat git diffitu tidak terlalu membantu. Saya telah mendengar tentang melakukan git config --global core.trustctime falseyang mungkin membantu, yang akan saya coba ketika saya kembali ke komputer dengan repositori di atasnya.

Saya mengubah detail sistem file dengan fakta! Dan saya mencoba git config --global core.trustctime falsetrik yang tidak berhasil dengan baik.

Saya memiliki masalah yang sama pada Mac setelah kloning repositori. Itu akan menganggap semua file telah diubah.

Setelah berjalan git config --global core.autocrlf input, masih menandai semua file sebagai berubah. Setelah mencari perbaikan saya menemukan .gitattributesfile di direktori home yang memiliki yang berikut.

* text=auto

Saya berkomentar dan repositori kloning lainnya mulai sekarang berfungsi dengan baik.

Saya mendapatkannya. Semua pengembang lain berada di Ubuntu (saya pikir) dan dengan demikian memiliki sistem file case-sensitive. Saya, bagaimanapun, tidak (karena saya di Mac). Memang, semua file memiliki huruf kecil kembar ketika saya melihatnya menggunakan git ls-tree HEAD <path>.

Saya akan meminta salah satu dari mereka untuk mengatasinya.

git config core.fileMode false

memecahkan masalah ini dalam kasus saya

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

TL; DR;

core.fileMode

Jika salah, perbedaan bit yang dapat dieksekusi antara indeks dan pohon kerja diabaikan; berguna pada sistem file yang rusak seperti FAT. Lihat git-update-index (1).

Default-nya benar, kecuali git-clone (1) atau git-init (1) akan menyelidiki dan menetapkan core.fileMode salah jika sesuai ketika repositori dibuat.

Saya berasumsi Anda menggunakan Windows. Halaman GitHub yang Anda tautkan memiliki detail mundur. Masalahnya adalah bahwa akhir baris CR + LF telah dikomit ke repositori dan karena Anda memiliki core.autocrlf yang disetel ke true atau input , Git ingin mengonversi akhiran baris ke LF, jadigit status menunjukkan bahwa setiap file diubah.

Jika ini adalah repositori yang hanya ingin Anda akses, tetapi tidak terlibat, Anda dapat menjalankan perintah berikut untuk hanya menyembunyikan masalah tanpa benar-benar menyelesaikannya.

git config core.autocrlf false

Jika ini adalah repositori yang Anda akan terlibat secara aktif dan dapat melakukan perubahan. Anda mungkin ingin memperbaiki masalah dengan membuat komit yang mengubah semua akhir baris dalam repositori untuk menggunakan LF alih-alih CR + LF dan kemudian mengambil langkah-langkah untuk mencegahnya terjadi lagi di masa mendatang.

Yang berikut ini diambil langsung dari halaman manual gitattributes dan harus dibentuk sebelumnya dari direktori kerja bersih.

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"

Jika ada file yang tidak dinormalisasi muncul di git status, hapus atribut teks mereka sebelum berjalan git add -u.

manual.pdf      -text

Sebaliknya, file teks yang tidak terdeteksi oleh Git dapat mengaktifkan normalisasi secara manual.

weirdchars.txt  text

Silakan jalankan perintah berikut. Itu mungkin bisa menyelesaikan masalah.

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

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

Di Visual Studio, jika Anda menggunakan Git, Anda dapat secara otomatis membuat file .gitignore dan .gitattributes. File .getattributes yang dibuat secara otomatis memiliki baris berikut:

* text=auto

Baris ini berada di dekat bagian atas file. Kami hanya perlu mengomentari baris dengan menambahkan # di depannya. Setelah melakukan itu, semuanya berjalan seperti yang diharapkan.

Masalahnya mungkin juga muncul dari izin file yang berbeda , seperti halnya kasus saya:

Repositori hasil kloning baru (Windows, Cygwin):

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

Repositori jarak jauh kosong (Linux):

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

Saya ingin menambahkan jawaban yang lebih terarah pada "Mengapa" ini terjadi, karena sudah ada jawaban yang bagus tentang cara memperbaikinya.

Jadi, .gitattributesmemiliki * text=autopengaturan, yang menyebabkan masalah ini.

Dalam kasus saya, file di cabang utama GitHub memiliki \r\nakhiran. Saya telah memutar pengaturan pada repositori untuk check-in dengan \nakhiran. Saya tidak tahu apa yang diperiksa Git. Seharusnya memeriksa dengan ujung asli ke kotak Linux saya ( \n), tapi saya kira itu memeriksa file dengan \r\nujung. Git mengeluh karena ia melihat \r\nakhiran yang diperiksa di repositori dan memperingatkan saya bahwa ia akan memeriksa \npengaturan. Karenanya file "harus dimodifikasi".

Itulah pengertian saya untuk saat ini.

Saya memiliki masalah yang sama. Juga dengan Mac. Melihat repositori pada mesin Linux saya perhatikan bahwa saya memiliki dua file:

geoip.dat dan GeoIP.dat

Saya menghapus yang sudah usang pada mesin Linux dan mengkloning repositori lagi ke Mac. Saya tidak dapat menarik, melakukan, menyimpan atau menarik dari salinan repositori saya ketika ada duplikat.

Masalah yang sama bagi saya. Saya bisa melihat beberapa gambar dengan nama yang sama, seperti "textField.png" dan "textfield.png" di repositori Git jarak jauh, tetapi tidak pada repositori lokal saya. Saya hanya dapat melihat "textField.png" yang tidak digunakan dalam kode proyek.

Ternyata sebagian besar rekan saya ada di Ubuntu menggunakan sistem file ext4 sedangkan saya di Mac menggunakan APFS.

Berkat jawaban Sam Elliott , solusinya cukup sederhana. Pertama saya meminta seorang kolega di Ubuntu untuk menghapus versi file yang berlebihan dengan huruf besar, kemudian komit dan tekan pada remote.

Kemudian saya menjalankan yang berikut:

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

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

Akhirnya, kami memutuskan bahwa setiap pengembang harus mengubah konfigurasi Git-nya untuk mencegah hal ini terjadi lagi:

# Local Git configuration
git config core.ignorecase = true

atau

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

Saya juga baru saja mengalami masalah yang sama. Dalam kasus saya, saya mengkloning repositori dan beberapa file segera hilang.

Ini disebabkan oleh path ke file dan nama file terlalu panjang untuk Windows. Untuk mengatasinya, klon repositori sedekat mungkin dengan root drive hard disk untuk mengurangi panjang jalur ke file. Misalnya, klon ke C:\A\GitRepobukan C:\Users Documents\yyy\Desktop\GitRepo.

Edit file yang disebut .git/config:

sudo gedit .git/config

Atau:

sudo vim .git/config

Isi

[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

Ubah filemode=truemenjadi filemode = false.

Untuk versi baru macOS ini dapat disebabkan oleh fitur keamanan OS.

Dalam repositori yang saya kerjakan, ada file biner yang memiliki * .app sebagai tipe file.

Itu hanya beberapa data serial, tetapi macOS memperlakukan semua file * .app sebagai aplikasi dan karena file ini tidak diunduh oleh pengguna, sistem menganggapnya tidak aman dan menambahkan com.apple.quarantineatribut file yang memastikan file tidak dapat dieksekusi.

Tetapi pengaturan atribut ini pada file juga mengubah file dan oleh karena itu muncul dalam set perubahan Git tanpa ada cara untuk mengembalikannya.

Anda dapat memeriksa apakah Anda memiliki masalah yang sama dengan menjalankan $ xattr file.app.

Solusinya cukup sederhana, selama Anda tidak harus bekerja dengan file tersebut. Tambahkan saja *.app binaryke .gitattributes.

Saya menyalin repositori lokal saya ke folder lain dan sekelompok file yang dimodifikasi muncul. Solusi saya adalah: Saya menyembunyikan file yang dimodifikasi dan menghapus simpanan . Repositori menjadi bersih.

Saya menemukan bahwa Git memperlakukan file saya (.psd dalam kasus ini) sebagai teks. Mengaturnya ke tipe biner di .gitattributes menyelesaikannya.

*.psd binary

Saya mencoba melakukan rebase interaktif, tetapi mengklaim ada beberapa file yang dimodifikasi, jadi tidak akan membiarkan saya melakukannya sekarang. Saya mencoba segalanya untuk kembali ke repositori bersih, tetapi tidak ada yang berhasil. Tidak ada jawaban lain yang membantu. Tapi ini akhirnya berhasil ...

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

Ledakan! Bersihkan repositori. Masalah terpecahkan. Kemudian saya hanya harus membuang komit terakhir ketika saya melakukan saya rebase -idan akhirnya semuanya bersih lagi. Aneh!

Kalau-kalau itu membantu orang lain, mungkin ada penyebab lain untuk masalah ini: versi Git yang berbeda. Saya menggunakan versi default yang diinstal dari Git pada kotak Ubuntu 18.04 (Bionic Beaver) dan semuanya bekerja dengan baik, tetapi ketika mencoba untuk mengkloning repositori menggunakan Git pada Ubuntu 16.04, beberapa file muncul sebagai dimodifikasi.

Tidak ada jawaban lain di sini yang memperbaiki masalah saya, tetapi memutakhirkan versi Git agar sesuai dengan kedua sistem memang memperbaiki masalah.