Perubahan tidak bertahap tersisa setelah git reset --hard


275

Setelah itu git reset --hard, git statusberi saya file di dalam Changes not staged for commit:bagian.

Saya juga sudah mencoba git reset ., git checkout -- .dan git checkout-index -f -a, tidak berhasil.

Jadi, bagaimana saya bisa menyingkirkan perubahan yang tidak dipentaskan?

Ini sepertinya mengenai hanya file proyek Visual Studio. Aneh. Lihat tempel ini: http://pastebin.com/eFZwPn9Z . Apa yang istimewa dengan file-file itu, adalah bahwa dalam .gitattributes yang saya miliki:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

Juga, autocrlfdisetel ke false di global saya .gitconfig. Mungkinkah itu relevan?


Apakah Anda menerapkan perintah-perintah itu dari root repositori? Perhatikan .singkatan direktori saat ini bukan direktori root
Alexander

1
Saya memang melakukannya dari repositori root.
Norswap

Apa gitversimu? Entah Anda membuat kesalahan konyol atau Anda memiliki versi lama yang buggy?
Shahbaz

Ini git 1.7.4 msysgit. Ini mungkin kesalahan, tetapi perintahnya tampak cukup sederhana, dan saya tidak dapat menemukan kesalahan.
Norswap

Sebagai catatan, saya mencoba menggunakan versi terbaru msysgit (1.7.11), tetapi masalahnya tetap ada.
Norswap

Jawaban:


361

Saya memiliki masalah yang sama dan itu terkait dengan .gitattributesfile tersebut. Namun tipe file yang menyebabkan masalah tidak ditentukan dalam .gitattributes.

Saya bisa menyelesaikan masalah dengan hanya menjalankan

git rm .gitattributes
git add -A
git reset --hard

7
Ini adalah * text = arahan otomatis dalam file gitattributes. Secara otomatis mengubah ujung file, sehingga file akan secara otomatis ditandai sebagai "dimodifikasi" ketika Anda memeriksa status.
Cody Django

3
Ini bekerja, tapi saya tidak mengerti persis mengapa. Adakah yang mau menjelaskan setiap perintah?
Edwin Stoteler

18
@NLwino, git rm .gitattributesmenghapus .gitattributes dari indeks. git add -Amenambahkan semua (termasuk penghapusan .gitattributes) untuk indeks, yang seharusnya maka hanya menjadi penghapusan .gitattributes, jika itu benar-benar masalah. git reset --hardmengatur ulang semua perubahan yang tidak dikomit, yang akan mencakup penghapusan .gitattributes. Pada dasarnya, ini mengabaikan .gitattributes (dan * text=autoarahan) untuk satu komit dengan menghapusnya, kemudian mengatur ulang indeks saat itu dihapus, oleh karena itu mengembalikannya, tetapi setelah Anda sudah mengatur ulang file lain, sehingga mereka tidak dimodifikasi lagi.
cloudworks

4
@GameScripting, Solusi ini tidak berfungsi untuk saya. Tidak ada file seperti .gitattributes: "fatal: pathspec '.gitattributes' tidak cocok dengan file mana pun"
Pacerier

4
Saya melakukan itu dan katanya fatal: pathspec '.gitattributes' did not match any files . Apa yang saya lakukan salah?
Sayang

136

TERSELESAIKAN!!!

Saya telah mengatasi masalah ini menggunakan langkah-langkah 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

Solusi adalah bagian dari langkah-langkah yang dijelaskan di situs git https://help.github.com/articles/dealing-with-line-endings/


5
INI BEKERJA ketika tidak ada yang lain! Kami telah mencoba segalanya dalam hal ini dan banyak utas lainnya - ini adalah tim pengembangan besar sehingga membuat semua orang di crlf yang sama telah menjadi mimpi buruk, tetapi ini menyelesaikan masalah.
tkersh

Menarik ... Saya menggunakan "git rm --chached <one_specific_file>, alih-alih menghapus semuanya." Git status "melaporkan file itu sebagai dihapus dan tidak dilacak. Kemudian" git reset --hard "perbaiki file itu dan semua file lain yang sedang dilaporkan sebagai "Perubahan tidak dipentaskan". (Sebelum menggunakan git rm, saya berusaha keras mengatur ulang keras untuk tidak berpengaruh). Saya suka sistem kontrol sumber misterius.
bergabung

Anda tahu, itu menghapus semua cache Anda. Dalam proyek besar itu bisa menghabiskan banyak waktu.
Ohar

Itu brutal. Anda bisa melakukan hal yang sama dengan menghapus direktori repo dan kloning ulang.
ingyhere

4
Pertimbangkan bahwa Anda menggunakan Windows dan tidak peka huruf besar-kecil. Jika Anda juga bekerja dengan pengembang yang menggunakan sistem file case-sensitive, seperti Mac atau Linux, mereka mungkin melakukan tag, cabang atau bahkan file dalam berbagai kasus. Dalam situasi itu indeks Anda akan menampilkan file yang ada yang ditimpa oleh OS ketika menarik. Satu-satunya cara untuk memperbaikinya adalah dengan melembagakan kebijakan penamaan di server Git Anda (kait) atau mengendus kesalahan sebelumnya.
ingyhere

97

Git tidak akan mengatur ulang file yang tidak ada di repositori. Jadi kamu bisa:

$ git add .
$ git reset --hard

Ini akan membuat semua perubahan, yang akan menyebabkan Git menyadari file-file itu, dan kemudian mengatur ulangnya.

Jika ini tidak berhasil, Anda dapat mencoba menyembunyikan dan menjatuhkan perubahan Anda:

$ git stash
$ git stash drop

4
File sudah dilacak. Tetap mencobanya dan tidak berhasil juga. Pasti ada sesuatu yang salah dengan repo saya, tetapi saya tidak tahu apa. Untuk informasi rahasia git, lihat jawaban saya untuk Shahbaz.
Norswap

Apa yang terjadi ketika Anda melakukan status git?
YuriAlbuquerque

1
Saya memikirkan solusi. Buat komit dan rebase interaktif untuk menghapus komit itu.
YuriAlbuquerque

Saya mencoba itu pada satu titik, dan itu berhasil, sulit saya kemudian mencobanya sekali lagi dan muncul dengan hasil mengejutkan yang diuraikan dalam edit jawaban saya.
Norswap

@ YuriAlbuquerque, Git tidak begitu mengerti POLA . Bukankah seluruh titik git reset --harduntuk " mengatur ulang area pementasan dan direktori kerja agar sesuai "? Jika suatu file tidak dipentaskan, jelas kami ingin menghapusnya saat melakukannya reset --hard.
Pacerier

71

Jika Anda menggunakan Git untuk Windows, kemungkinan ini adalah masalah Anda

Saya memiliki masalah dan simpanan yang sama, hard reset, bersih atau bahkan semuanya masih meninggalkan perubahan. Apa yang menjadi masalah adalah mode file x yang tidak diatur dengan benar oleh git. Ini adalah "masalah yang diketahui" dengan git untuk windows. Perubahan lokal menunjukkan dalam status gitk dan git sebagai mode lama 100755 mode baru 100644, tanpa perbedaan file yang sebenarnya.

Cara mengatasinya adalah dengan mengabaikan mode file:

git config core.filemode false

Info lebih lanjut di sini


2
Ini bekerja bahkan ketika rm -rf *; git checkout HEAD .tidak. Fiuh!
forumulator

Bekerja untuk saya, sementara drop / hard reset / rm simpanan semua gagal.
kakyo

Ini juga bekerja untuk saya ketika saya punya masalah bekerja dengan git repo di Linux yang di-host pada Mac
prmph

bekerja untuk saya - mencoba segala sesuatu yang lain dan ya mode lama vs mode baru adalah masalahnya (perhatikan saya memiliki nomor yang berbeda tetapi file yang sama)
Taehoon A Kim

Penghemat waktu dan hidup.
Yogesh Patil

31

Oke, saya sudah memecahkan masalah.

Tampaknya .gitattributesfile itu, berisi:

*.sln        eol=crlf
*.vcproj     eol=crlf
*.vcxproj*   eol=crlf

membuat file proyek tampak tidak panggung. Saya tidak mengerti mengapa demikian, dan saya benar-benar berharap seseorang yang mengetahui cara-cara git akan memberi kita penjelasan yang bagus.

Perbaikan saya adalah menghapus file-file ini, dan menambahkan di autocrlf = falsebawah[core].git/config .

Ini tidak sama persis dengan konfigurasi sebelumnya, karena memerlukan setiap pengembang untuk memilikinya autocrlf = false . Saya ingin mencari perbaikan yang lebih baik.

EDIT:

Saya mengomentari garis memberatkan, membatalkan komentar dan itu berhasil. Apa ... aku bahkan tidak ...!


1
Saya baru saja mengalami masalah yang sama persis ini dan ini adalah satu-satunya solusi yang berhasil. Dalam kasus saya, saya beralih dari cabang fitur ke master saya dan menarik beberapa perubahan baru dari hulu dan itu baru mulai terjadi untuk 2 file yang dimodifikasi. Sepertinya file mungkin telah beralih dari Unix ke ujung jalur Windows yang mungkin ada hubungannya dengan itu. Tidak yakin bagaimana atau mengapa.
Steven Surowiec

+1 Masalah yang sama pada Windows Git. Sudah autocrlf = false. Saya menggabungkan perubahan dari upo svn repo ( git svn fetch/ git merge git-svn) dan dibiarkan dengan 1 file ditandai sebagai dimodifikasi. Yang aneh adalah bahwa saya pernah mengalami masalah ini sebelumnya dan yang perlu saya lakukan adalah memeriksa cabang lain (dengan -fbendera), dan kemudian beralih kembali. Saya melakukan itu, dan itu berhasil, tetapi ketika saya beralih ke cabang fitur, "perubahan" telah kembali! Hasil edit Anda di bagian bawah jawaban adalah solusinya. Dalam kasus saya, saya berkomentar / menghapus komentar satu baris di bagian atas file .gitattributes saya:* text=auto !eol
Aaron Blenkush

1
EDIT itu juga bekerja untuk saya: beri komentar pada baris .gitattributes, jalankan git status, batalkan komentar pada baris tersebut .gitattributes, jalankan git statuslagi
Ignitor

Ini karena git sedang mengatur ulang file-file itu, lalu menerapkan akhiran baris yang ditentukan dalam .gitattributeslagi. The git diffmungkin menunjukkan terkenal dinding merah / dinding hijau yang khas dari perbedaan line-berakhir.
Dagrooms

21

Kemungkinan Penyebab # 1 - Normalisasi Akhir Baris

Satu situasi di mana ini bisa terjadi adalah ketika file tersebut diperiksa ke dalam repositori tanpa konfigurasi yang benar untuk akhir baris (1) menghasilkan file dalam repositori dengan salah satu akhir baris yang salah, atau akhir baris campuran. Untuk mengonfirmasi, verifikasi yang git diffhanya menunjukkan perubahan di akhir baris (ini mungkin tidak terlihat secara default, coba git diff | cat -vlihat carriage return sebagai ^Mkarakter literal ).

Selanjutnya, seseorang mungkin menambahkan .gitattributesatau mengubah core.autocrlfpengaturan untuk menormalkan akhir baris (2). Berdasarkan pada .gitattributesatau konfigurasi global, Git telah menerapkan perubahan lokal pada copy pekerjaan Anda yang menerapkan normalisasi akhir baris yang diminta. Sayangnya, untuk beberapa alasan git reset --hardtidak membatalkan perubahan normalisasi garis ini.

Larutan

Penanganan masalah di mana ujung jalur lokal diatur ulang tidak akan menyelesaikan masalah. Setiap kali file "dilihat" oleh git, ia akan mencoba dan menerapkan kembali normalisasi, menghasilkan masalah yang sama.

Pilihan terbaik adalah membiarkan git menerapkan normalisasi yang diinginkannya dengan menormalisasi semua akhir baris dalam repo agar sesuai dengan .gitattributes, dan melakukan perubahan itu - lihat Mencoba memperbaiki akhir baris dengan git-cabang-filter, tetapi tidak berhasil .

Jika Anda benar-benar ingin mencoba dan mengembalikan perubahan ke file secara manual maka solusi termudah tampaknya menghapus file yang dimodifikasi, dan kemudian memberitahu git untuk mengembalikannya, walaupun saya perhatikan solusi ini tampaknya tidak bekerja secara konsisten 100% dari waktu ( PERINGATAN: JANGAN jalankan ini jika file Anda yang dimodifikasi memiliki perubahan selain dari akhir baris !!):

    git status --porcelain | grep "^ M" | cut -c4- | xargs rm
    git checkout -- .

Perhatikan bahwa, kecuali jika Anda menormalkan akhir baris di repositori di beberapa titik, Anda akan terus mengalami masalah ini.

Kemungkinan Penyebab # 2 - Ketidaksensitifan Kasus

Penyebab kedua yang mungkin adalah ketidakpekaan huruf pada Windows atau Mac OS / X. Misalnya, katakan path seperti yang berikut ini ada di repositori:

/foo/bar

Sekarang seseorang di Linux melakukan file ke /foo/Bar(mungkin karena alat membangun atau sesuatu yang membuat direktori itu) dan mendorong. Di Linux, ini sebenarnya sekarang adalah dua direktori yang terpisah:

/foo/bar/fileA
/foo/Bar/fileA

Memeriksa repo ini pada Windows atau Mac dapat mengakibatkan modifikasi fileAyang tidak dapat direset, karena pada setiap reset, git pada Windows memeriksa /foo/bar/fileA, dan kemudian karena Windows tidak peka huruf besar-kecil, menimpa konten fileAdengan/foo/Bar/fileA , yang mengakibatkan mereka "dimodifikasi".

Kasus lain mungkin merupakan file individual yang ada dalam repo, yang ketika diperiksa pada sistem file case tidak sensitif, akan tumpang tindih. Sebagai contoh:

/foo/bar/fileA
/foo/bar/filea

Mungkin ada situasi serupa lainnya yang dapat menyebabkan masalah seperti itu.

git pada kasus filesystem tidak sensitif harus benar-benar mendeteksi situasi ini dan menunjukkan pesan peringatan yang bermanfaat, tetapi saat ini tidak (ini dapat berubah di masa depan - lihat diskusi ini dan usulan tambalan terkait pada milis git.git).

Larutan

Solusinya adalah untuk membawa kasus file dalam indeks git dan kasus pada sistem file Windows menjadi sejajar. Ini bisa dilakukan di Linux yang akan menunjukkan keadaan sebenarnya, ATAU di Windows dengan utilitas open source yang sangat berguna Git-Unite . Git-Unite akan menerapkan perubahan kasus yang diperlukan untuk indeks git, yang kemudian dapat dilakukan untuk repo.

(1) Ini kemungkinan besar dilakukan oleh seseorang yang menggunakan Windows, tanpa .gitattributesdefinisi untuk file yang dimaksud, dan menggunakan pengaturan global default untuk core.autocrlfyang mana adalah false(lihat (2)).

(2) http://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/


Sialan, lakukan semua ini. Saya harus melakukan setelah baris pertama tetapi saya akhirnya bisa checkout master. Itu tidak menyenangkan.
Tim Lieberman

16

Jika jawaban lain tidak berfungsi, coba tambahkan file, lalu setel ulang

$ git add -A
$ git reset --hard

Dalam kasus saya, ini membantu ketika ada banyak file kosong yang dilacak git.


Ini bekerja. Saya hanya menggunakan $ git add .bukan$ git add -A
Bjarne Gerhardt-Pedersen

8

Penyebab lain untuk ini mungkin sistem file case-insensitive . Jika Anda memiliki beberapa folder di repo Anda pada tingkat yang sama yang namanya hanya berbeda per kasus, Anda akan terkena dampaknya. Jelajahi repositori sumber menggunakan antarmuka webnya (mis. GitHub atau VSTS) untuk memastikan.

Untuk informasi lebih lanjut: https://stackoverflow.com/a/2016426/67824


Untuk menemukan nama-nama file tersebut jalankangit ls-tree -r --name-only HEAD | tr A-Z a-z | sort | uniq -d
Diomidis Spinellis

5

Anda dapat stashmenghapus perubahan Anda, lalu membuang simpanan:

git stash
git stash drop

1
Anda mungkin juga tertarik dengan ini .
Shahbaz

5

Tak satu pun dari metode ini bekerja untuk saya, satu-satunya solusi adalah dengan membatalkan seluruh repo dan mengkloningnya. Ini termasuk menyimpan, mengatur ulang, menambahkan kemudian mengatur ulang, pengaturan CLRF, sensitivitas huruf dll.


Pembaruan, ternyata filesystem case sensitif yang saya pasang tidak benar-benar case sensitif. Setelah saya perbaiki bahwa masalah ini dapat diperbaiki menggunakan teknik yang disebutkan di atas.
John Hunt

4

Jalankan perintah bersih :

# Remove all untracked files and directories. (`-f` is `force`, `-d` is `remove directories`)

git clean -fd

3
Sayangnya ini tidak menyelesaikan masalah yang terkait dengan akhir baris.
Christopher Schneider

Ini hanya hal yang menyelesaikan masalah saya, apa pun masalah saya. Saya tidak punya .gitattributesakhiran file dan baris tidak menjadi masalah karena saya di kotak linux dan semua devs dan server kami adalah linux.
Samuel Neff

4

Periksa .gitattributes.

Dalam kasus saya, saya punya *.js text eol=lfdi dalamnya dan opsi git core.autocrlfadalah true.

Ini membawa saya ke situasi ketika git secara otomatis mengkonversi akhir baris file saya dan mencegah saya untuk memperbaikinya dan bahkan git reset --hard HEADtidak melakukan apa-apa.

Saya memperbaikinya dengan berkomentar *.js text eol=lfdi saya .gitattributesdan membatalkan komentar setelahnya.

Sepertinya itu hanya sihir git.


Ini untuk saya, meningkatkan proyek saya yang diperkenalkan *.bat text eol=crlfke proyek saya.
Leo

1

Saya mengalami masalah serupa juga melibatkan .gitattributes, tetapi untuk kasus saya melibatkan LFS GitHub. Meskipun ini bukan skenario OP, saya pikir ini memberikan kesempatan untuk menggambarkan apa yang dilakukan .gitattributesfile dan mengapa hal itu dapat menyebabkan perubahan yang tidak dipentaskan dalam bentuk perbedaan "hantu".

Dalam kasus saya, file sudah ada di repositori saya, seperti sejak awal waktu. Dalam komit baru-baru ini, saya menambahkan git-lfs trackaturan baru menggunakan pola yang agak terlalu luas di belakang, dan akhirnya cocok dengan file kuno ini. Saya tahu saya tidak ingin mengubah file ini; Saya tahu saya tidak mengubah file, tetapi sekarang file itu dalam perubahan saya yang tidak dipentaskan dan tidak ada jumlah checkout atau hard reset pada file yang akan memperbaikinya. Mengapa?

Ekstensi GitHub LFS terutama bekerja dengan memanfaatkan kait yang gitmenyediakan akses melalui .gitattributesfile. Secara umum, entri dalam .gitattributesmenentukan bagaimana file yang cocok harus diproses. Dalam kasus OP, itu berkaitan dengan normalisasi ujung garis; di tambang, itu adalah apakah membiarkan LFS menangani penyimpanan file. Dalam kedua kasus, file sebenarnya yang gitdilihat saat menghitung a git difftidak cocok dengan file yang Anda lihat saat Anda memeriksa file. Oleh karena itu, jika Anda mengubah cara file diproses melalui .gitattributespola yang cocok dengan itu, itu akan muncul sebagai perubahan yang tidak dipentaskan dalam laporan status, bahkan jika benar-benar tidak ada perubahan dalam file.

Semua yang mengatakan, "jawaban" saya untuk pertanyaan adalah bahwa jika perubahan dalam .gitattributesfile adalah sesuatu yang ingin Anda lakukan, Anda harus benar-benar hanya menambahkan perubahan dan melanjutkan. Jika tidak, maka ubah .gitattributesuntuk lebih mewakili apa yang ingin Anda lakukan.

Referensi

  1. Spesifikasi GitHub LFS - Deskripsi hebat tentang bagaimana mereka menghubungkan ke dalam cleandan smudgepanggilan fungsi untuk mengganti file Anda di gitobjek dengan file teks sederhana dengan hash.

  2. gitattributes Documentation - Semua detail tentang apa yang tersedia untuk menyesuaikan cara gitmemproses dokumen Anda.


0

Saya memiliki masalah yang sama. Saya lakukan git reset --hard HEADtetapi masih setiap kali saya lakukan git statussaya melihat beberapa file yang dimodifikasi.

Solusi saya relatif sederhana. Saya baru saja menutup IDE saya (ini Xcode) dan menutup baris perintah saya (ini terminal pada Mac OS saya) dan mencobanya lagi dan berhasil.

Namun saya tidak pernah dapat menemukan apa yang menjadi sumber masalahnya.


0

Saya percaya bahwa ada masalah dengan git untuk Windows di mana git secara acak menulis akhir baris yang salah pada checkout dan satu-satunya solusi adalah dengan checkout beberapa cabang lain dan memaksa git untuk mengabaikan perubahan. Kemudian checkout cabang yang ingin Anda kerjakan.

git checkout master -f
git checkout <your branch>

Ketahuilah bahwa ini akan membuang segala perubahan yang mungkin Anda lakukan dengan sengaja, jadi lakukan saja ini jika Anda memiliki masalah ini segera setelah checkout.

Sunting: Saya mungkin benar-benar beruntung pertama kali. Ternyata saya mendapat bit lagi setelah berganti cabang. Ternyata file git dilaporkan telah dimodifikasi setelah mengubah cabang berubah. (Rupanya karena git tidak secara konsisten menerapkan baris CRLF yang berakhir pada file dengan benar.)

Saya memperbarui ke git terbaru untuk Windows dan berharap masalahnya hilang.


0

Masalah serupa, meski saya yakin hanya di permukaan. Bagaimanapun, ini dapat membantu seseorang: apa yang saya lakukan (FWIW, dalam SourceTree): menyimpan file yang tidak dikomit, kemudian melakukan reset keras.


0

Seperti jawaban lain telah tunjukkan, masalahnya adalah karena koreksi otomatis line-end. Saya mengalami masalah ini dengan file * .svg. Saya menggunakan file svg untuk ikon dalam proyek saya.

Untuk mengatasi masalah ini, saya beri tahu git bahwa file svg harus diperlakukan sebagai biner alih-alih teks dengan menambahkan baris di bawah ini ke .gitattributes

* .svg biner


0

Dalam situasi yang sama. Sebagai hasil dari bertahun-tahun siksaan dengan banyak programmer yang mampu memasukkan berbagai penyandian dari ujung garis (. Asp , .js, .css ... bukan esensi) ke dalam satu file. Beberapa waktu lalu menolak .gitattributes. Pengaturan untuk repo kiri autorclf = truedan safecrlf = warn.

Masalah terakhir muncul ketika menyinkronkan dari arsip dengan ujung garis yang berbeda. Setelah menyalin dari arsip, dalam status git banyak file diubah dengan catatan

The line will have its original line endings in your working directory. warning: LF will be replaced by CRLF in ...

Kiat dari Bagaimana cara menormalkan ujung-ujung garis pohon yang berfungsi di Git? membantu

git add -u


0

Kemungkinan lain yang saya temui adalah bahwa salah satu paket di repositori berakhir dengan HEAD terpisah. Jika tidak ada jawaban di sini yang membantu dan Anda menemukan pesan status git seperti ini, Anda mungkin memiliki masalah yang sama:

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

        modified:   path/to/package (new commits)

Masuk ke path/to/packagefolder a git statusharus menghasilkan hasil berikut:

HEAD detached at 7515f05

Dan perintah berikut harus memperbaiki masalah, di mana masterharus diganti oleh cabang lokal Anda:

git checkout master

Dan Anda akan mendapatkan pesan bahwa cabang lokal Anda akan memiliki sejumlah komitmen di belakang cabang jarak jauh. git pulldan kamu harus keluar dari hutan!


Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.