Bất cứ khi nào tôi kéo từ điều khiển từ xa, tôi gặp lỗi sau về nén. Khi tôi chạy nén thủ công, tôi cũng nhận được như vậy:

$ git gc
error: Could not read 3813783126d41a3200b35b6681357c213352ab31
fatal: bad tree object 3813783126d41a3200b35b6681357c213352ab31
error: failed to run repack

Có ai biết, phải làm gì về điều đó?

Từ tập tin mèo tôi nhận được điều này:

$ git cat-file -t 3813783126d41a3200b35b6681357c213352ab31
error: unable to find 3813783126d41a3200b35b6681357c213352ab31
fatal: git cat-file 3813783126d41a3200b35b6681357c213352ab31: bad file

Và từ git fsck tôi nhận được điều này (không biết nó có thực sự liên quan không):

$ git fsck
error: inflate: data stream error (invalid distance too far back)
error: corrupt loose object '45ba4ceb93bc812ef20a6630bb27e9e0b33a012a'
fatal: loose object 45ba4ceb93bc812ef20a6630bb27e9e0b33a012a (stored in .git/objects/45/ba4ceb93bc812ef20a6630bb27e9e0b33a012a) is corrupted

Bất cứ ai có thể giúp tôi giải mã điều này?

Hình như bạn có một đối tượng cây hỏng. Bạn sẽ cần phải có được đối tượng đó từ người khác. Hy vọng họ sẽ có một phiên bản chưa được sửa chữa.

Bạn thực sự có thể xây dựng lại nó nếu bạn không thể tìm thấy một phiên bản hợp lệ từ người khác bằng cách đoán xem nên có tập tin nào ở đó. Bạn có thể muốn xem ngày & giờ của các đối tượng có khớp với nó không. Đó có thể là những đốm màu liên quan. Bạn có thể suy ra cấu trúc của đối tượng cây từ những đối tượng đó.

Hãy xem Git Screencasts của Scott Chacon liên quan đến nội bộ git. Điều này sẽ cho bạn thấy cách git hoạt động dưới mui xe và cách thực hiện công việc thám tử này nếu bạn thực sự bị mắc kẹt và không thể lấy đối tượng đó từ người khác.

Tôi đã có cùng một vấn đề (không biết tại sao).

Khắc phục sự cố này yêu cầu quyền truy cập vào một bản sao từ xa chưa được lưu trữ của kho lưu trữ và sẽ giữ nguyên bản sao làm việc tại địa phương của bạn.

Nhưng nó có một số nhược điểm:

• Bạn sẽ mất hồ sơ của bất kỳ cam kết nào không được đẩy, và sẽ phải giới thiệu chúng.
• Bạn sẽ mất bất kỳ stash.

Cách khắc phục

Thực hiện các lệnh này từ thư mục mẹ phía trên repo của bạn (thay thế 'foo' bằng tên của thư mục dự án của bạn):

1. Tạo một bản sao lưu của thư mục bị hỏng:
   cp -R foo foo-backup
2. Tạo một bản sao mới của kho lưu trữ từ xa vào một thư mục mới:
   git clone git@www.mydomain.de:foo foo-newclone
3. Xóa thư mục con .git bị hỏng:
   rm -rf foo/.git
4. Di chuyển thư mục con .git mới được nhân bản vào foo:
   mv foo-newclone/.git foo
5. Xóa phần còn lại của bản sao mới tạm thời:
   rm -rf foo-newclone

Trên Windows, bạn sẽ cần sử dụng:

• copy thay vì cp -R
• rmdir /S thay vì rm -rf
• move thay vì mv

Bây giờ foo đã có .gitthư mục con gốc , nhưng tất cả các thay đổi cục bộ vẫn còn đó. git status, commit, pull, push,, Vv hoạt động trở lại khi họ cần.

Đặt cược tốt nhất của bạn có lẽ chỉ đơn giản là sao chép lại từ repo từ xa (ví dụ: Github hoặc khác). Thật không may, bạn sẽ mất bất kỳ cam kết nào chưa được xử lý và thay đổi được lưu lại, tuy nhiên bản sao làm việc của bạn vẫn còn nguyên.

Đầu tiên tạo một bản sao lưu các tập tin cục bộ của bạn. Sau đó, làm điều này từ gốc của cây làm việc của bạn:

rm -fr .git
git init
git remote add origin [your-git-remote-url]
git fetch
git reset --mixed origin/master
git branch --set-upstream-to=origin/master master  

Sau đó cam kết bất kỳ tập tin thay đổi khi cần thiết.

Làm việc trên máy ảo, trong máy tính xách tay của tôi, pin chết, gặp lỗi này;

lỗi: tệp đối tượng .git / object / ce / theRef là lỗi rỗng: tệp đối tượng .git / object / ce / theRef trống

Tôi đã quản lý để làm cho repo hoạt động trở lại chỉ với 2 lệnh và không mất công việc của mình (tệp đã sửa đổi / thay đổi không được cam kết)

find .git/objects/ -size 0 -exec rm -f {} \;
git fetch origin

Sau đó tôi chạy một git status, repo vẫn ổn và có những thay đổi của tôi (chờ đợi để được cam kết, hãy làm ngay bây giờ ..).

phiên bản git 1.9.1

Hãy nhớ sao lưu tất cả các thay đổi bạn nhớ, chỉ trong trường hợp giải pháp này không hiệu quả và cần một cách tiếp cận triệt để hơn.

Máy tính của tôi bị hỏng trong khi tôi đang viết một tin nhắn cam kết. Sau khi khởi động lại, cây làm việc giống như tôi đã rời khỏi nó và tôi đã có thể thực hiện thành công các thay đổi của mình.

Tuy nhiên, khi tôi cố chạy git statustôi đã nhận

error: object file .git/objects/xx/12345 is empty
fatal: loose object xx12345 (stored in .git/objects/xx/12345 is corrupt

Không giống như hầu hết các câu trả lời khác, tôi đã không cố gắng khôi phục bất kỳ dữ liệu nào . Tôi chỉ cần Git ngừng phàn nàn về tệp đối tượng trống.

Tổng quat

"Tệp đối tượng" là biểu diễn băm của git của một tệp thực mà bạn quan tâm. Git nghĩ rằng nó nên có một phiên bản băm some/file.whateverđược lưu trữ .git/object/xx/12345và việc sửa lỗi hóa ra chủ yếu là vấn đề tìm ra tệp "đối tượng lỏng lẻo" nào được cho là đại diện.

Chi tiết

Các tùy chọn có thể có vẻ là

1. Xóa tập tin trống
2. Đưa tệp vào trạng thái chấp nhận được với Git

Cách tiếp cận 1: Xóa tệp đối tượng

Điều đầu tiên tôi thử chỉ là di chuyển tệp đối tượng

mv .git/objects/xx/12345 ..

Điều đó không hiệu quả - git bắt đầu phàn nàn về một liên kết bị hỏng. Tiếp cận 2.

Cách tiếp cận 2: Sửa tệp

Linus Torvalds có một bài viết tuyệt vời về cách phục hồi tệp đối tượng đã giải quyết vấn đề cho tôi. Các bước chính được tóm tắt ở đây.

$> # Find out which file the blob object refers to
$> git fsck
broken link from    tree 2d9263c6d23595e7cb2a21e5ebbb53655278dff8
           to    blob xx12345
missing blob xx12345

$> git ls-tree 2d926
...
10064 blob xx12345  your_file.whatever

Điều này cho bạn biết tập tin nào mà đối tượng trống được cho là hàm băm của. Bây giờ bạn có thể sửa chữa nó.

$> git hash-object -w path/to/your_file.whatever

Sau khi làm điều này tôi đã kiểm tra .git/objects/xx/12345, nó không còn trống nữa và git ngừng phàn nàn.

Thử

git stash

Điều này làm việc cho tôi. Nó khắc phục bất cứ điều gì bạn chưa cam kết và điều đó đã giải quyết vấn đề.

Một bộ sưu tập rác đã khắc phục vấn đề của tôi:

git gc --aggressive --prune=now

Mất một lúc để hoàn thành, nhưng mọi đối tượng lỏng lẻo và / hoặc chỉ mục bị hỏng đã được sửa.

chỉ đơn giản là chạy một git prunevấn đề cố định cho tôi

Tôi mới trải nghiệm điều này - máy của tôi bị hỏng trong khi viết cho repo Git, và nó bị hỏng. Tôi đã sửa nó như sau.

Tôi đã bắt đầu với việc xem xét bao nhiêu cam kết mà tôi đã không bị đẩy vào repo từ xa, do đó:

gitk &

Nếu bạn không sử dụng công cụ này thì nó rất tiện dụng - có sẵn trên tất cả các hệ điều hành theo như tôi biết. Điều này chỉ ra rằng điều khiển từ xa của tôi đã thiếu hai lần xác nhận. Do đó, tôi đã nhấp vào nhãn cho biết cam kết từ xa mới nhất (thường là như vậy /remotes/origin/master) để có được hàm băm (hàm băm dài 40 ký tự, nhưng để đơn giản tôi đang sử dụng 10 ở đây - dù sao thì nó vẫn hoạt động).

Đây là:

14c0fcc9b3

Sau đó tôi nhấp vào cam kết sau (tức là lần đầu tiên mà điều khiển từ xa không có) và nhận được hàm băm ở đó:

04d44c3298

Sau đó tôi sử dụng cả hai thứ này để tạo một bản vá cho cam kết này:

git diff 14c0fcc9b3 04d44c3298 > 1.patch

Sau đó, tôi đã làm tương tự với các cam kết bị thiếu khác, tức là tôi đã sử dụng hàm băm của cam kết trước đó và hàm băm của chính xác nhận đó:

git diff 04d44c3298 fc1d4b0df7 > 2.patch

Sau đó tôi chuyển đến một thư mục mới, nhân bản repo từ xa:

git clone git@github.com:username/repo.git

Sau đó tôi đã di chuyển các tệp vá vào thư mục mới, áp dụng chúng và cam kết chúng với các thông điệp cam kết chính xác của chúng (chúng có thể được dán từ git loghoặc gitkcửa sổ):

patch -p1 < 1.patch
git commit

patch -p1 < 2.patch
git commit

Điều này khôi phục lại cho tôi (và lưu ý có lẽ có một cách nhanh hơn để làm điều đó cho một số lượng lớn các cam kết). Tuy nhiên tôi rất muốn xem liệu cây trong repo bị hỏng có thể được sửa chữa hay không, và câu trả lời là nó có thể. Với một repo đã sửa chữa có sẵn như trên, hãy chạy lệnh này trong thư mục bị hỏng:

git fsck 

Bạn sẽ nhận được một cái gì đó như thế này:

error: object file .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d is empty
error: unable to find ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d
error: sha1 mismatch ca539ed815fefdbbbfae6e8d0c0b3dbbe093390d

Để sửa chữa, tôi sẽ làm điều này trong thư mục bị hỏng:

rm .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d
cp ../good-repo/.git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d .git/objects/ca/539ed815fefdbbbfae6e8d0c0b3dbbe093390d

tức là loại bỏ các tập tin bị hỏng và thay thế nó bằng một tập tin tốt. Bạn có thể phải làm điều này nhiều lần. Cuối cùng sẽ có một điểm mà bạn có thể chạy fsckmà không gặp lỗi. Bạn có thể sẽ có dòng "dangling commit" và "dangling blob" trong báo cáo, đây là hậu quả của sự nổi loạn của bạn và sửa đổi trong thư mục này, và đều ổn. Người thu gom rác sẽ loại bỏ chúng trong khóa học do.

Do đó (ít nhất là trong trường hợp của tôi), một cây bị hỏng không có nghĩa là các cam kết không được đánh dấu bị mất.

Tôi đã nhận được một lỗi đối tượng lỏng lẻo là tốt.

./objects/x/x

Tôi đã sửa nó thành công bằng cách vào thư mục của đối tượng bị hỏng. Tôi thấy rằng người dùng được gán cho đối tượng đó không phải là người dùng git của tôi. Tôi không biết làm thế nào nó xảy ra, nhưng tôi đã chạy một chown git:gittập tin đó và sau đó nó hoạt động trở lại.

Đây có thể là một sửa chữa tiềm năng cho các vấn đề của một số người nhưng không cần thiết tất cả chúng.

Tôi đã gặp lỗi này sau khi máy (windows) của tôi quyết định tự khởi động lại. Rất may, repo từ xa của tôi đã được cập nhật vì vậy tôi mới thực hiện một bản sao mới.

Runnning đã git stash; git stash popkhắc phục vấn đề của tôi

Tôi đã làm theo nhiều bước khác ở đây; Mô tả của Linus về cách nhìn vào cây / vật git và tìm thấy những gì còn thiếu đặc biệt hữu ích. git-git phục hồi blob bị hỏng

Nhưng cuối cùng, đối với tôi, tôi đã có các đối tượng cây bị lỏng / hỏng do lỗi một phần đĩa và các đối tượng cây không dễ dàng phục hồi / không được bao phủ bởi tài liệu đó.

Cuối cùng, tôi đã chuyển xung đột objects/<ha>/<hash>ra khỏi đường đi và được sử dụng git unpack-objectsvới một tập tin gói từ một bản sao hợp lý được cập nhật. Nó đã có thể khôi phục các đối tượng cây bị mất tích.

Vẫn để lại cho tôi rất nhiều đốm màu lơ lửng, có thể là tác dụng phụ của việc giải nén các công cụ lưu trữ trước đó và được giải quyết trong các câu hỏi khác tại đây

Trả lời @ user1055643 thiếu bước cuối cùng:

$ rm -fr .git
$ git init
$ git remote add origin your-git-remote-url
$ git fetch
$ git reset --hard origin/master
$ git branch --set-upstream-to=origin/master master  

Chúng tôi chỉ có trường hợp ở đây. Nó đã xảy ra rằng vấn đề là quyền sở hữu của tệp bị hỏng là root thay vì người dùng bình thường của chúng tôi. Điều này được gây ra bởi một cam kết được thực hiện trên máy chủ sau khi ai đó đã thực hiện "sudo su -".

Đầu tiên, xác định tệp bị hỏng của bạn bằng:

$> git fsck --full

Bạn sẽ nhận được câu trả lời như thế này:

fatal: loose object 11b25a9d10b4144711bf616590e171a76a35c1f9 (stored in .git/objects/11/b25a9d10b4144711bf616590e171a76a35c1f9) is corrupt

Đi vào thư mục chứa tệp bị hỏng và thực hiện:

$> ls -la

Kiểm tra quyền sở hữu của tập tin bị hỏng. Nếu khác, chỉ cần quay lại gốc của repo của bạn và thực hiện:

$> sudo chown -R YOURCORRECTUSER:www-data .git/

Hy vọng nó giúp!

Đối với tôi điều này xảy ra do mất điện trong khi làm a git push.

Các tin nhắn trông như thế này:

$ git status
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
error: object file .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74 is empty
fatal: loose object c238824eb3fb602edc2c49fccb535f9e53951c74 (stored in .git/objects/c2/38824eb3fb602edc2c49fccb535f9e53951c74) is corrupt

Tôi đã thử những thứ như thế git fscknhưng điều đó không giúp được gì. Vì sự cố đã xảy ra trong một git push, rõ ràng nó đã xảy ra trong quá trình viết lại ở phía máy khách xảy ra sau khi máy chủ được cập nhật. Tôi nhìn xung quanh và nhận ra rằng c2388trong trường hợp của tôi là một đối tượng cam kết, bởi vì nó được gọi bằng các mục trong .git/refs. Vì vậy, tôi biết rằng tôi sẽ có thể tìm thấy c2388khi tôi nhìn vào lịch sử (thông qua giao diện web hoặc bản sao thứ hai).

Trên bản sao thứ hai tôi đã làm một git log -n 2 c2388để xác định tiền thân của c2388. Sau đó, tôi tự sửa đổi .git/refs/heads/mastervà .git/refs/remotes/origin/mastertrở thành người tiền nhiệm c2388thay vì c2388. Sau đó tôi có thể làm một git fetch. Việc git fetchthất bại một vài lần cho các xung đột trên các đối tượng trống rỗng. Tôi loại bỏ từng đối tượng trống cho đến khi git fetchthành công. Điều đó đã chữa lành kho lưu trữ.

Tôi đã giải quyết theo cách này: Tôi quyết định chỉ cần sao chép tệp đối tượng chưa được sửa chữa từ bản sao của bản sao lưu vào kho lưu trữ ban đầu của tôi. Điều này làm việc như là tốt. (Nhân tiện: Nếu bạn không thể tìm thấy đối tượng trong .git / object / theo tên của nó, thì có lẽ nó đã được [đóng gói] [pack] để bảo tồn không gian.)

Tôi đã có vấn đề tương tự trong repo git từ xa trần của tôi. Sau nhiều lần khắc phục sự cố, tôi đã tìm ra một trong những đồng nghiệp của mình đã thực hiện một cam kết trong đó một số tệp trong .git / object có quyền 440 (r - r -----) thay vì 444 (r - r - r -). Sau khi yêu cầu đồng nghiệp thay đổi quyền với "đối tượng chmod 444 -R" bên trong repo trần, vấn đề đã được khắc phục.

Tôi chỉ có một vấn đề như thế này. Vấn đề cụ thể của tôi là do sự cố hệ thống làm hỏng cam kết gần đây nhất (và do đó cũng là nhánh chính). Tôi đã không thúc ép và muốn thực hiện lại cam kết đó. Trong trường hợp cụ thể của tôi, tôi đã có thể xử lý nó như thế này:

1. Tạo một bản sao lưu của .git/:rsync -a .git/ git-bak/
2. Kiểm tra .git/logs/HEADvà tìm dòng cuối cùng với ID cam kết hợp lệ. Đối với tôi, đây là lần cam kết gần đây thứ hai. Điều này là tốt, bởi vì tôi vẫn có các phiên bản thư mục làm việc của tệp, và vì vậy mọi phiên bản tôi muốn.
3. Tạo một nhánh tại cam kết đó: git branch temp <commit-id>
4. làm lại các cam kết bị hỏng với các tệp trong thư mục làm việc.
5. git reset master temp để di chuyển nhánh chính sang cam kết mới mà bạn đã thực hiện ở bước 2.
6. git checkout mastervà kiểm tra xem có vẻ đúng với git log.
7. git branch -d temp.
8. git fsck --fullvà bây giờ sẽ an toàn để xóa mọi đối tượng bị hỏng mà fsck tìm thấy.
9. Nếu tất cả có vẻ tốt, hãy thử đẩy. Nếu nó hoạt động,

Điều đó làm việc cho tôi. Tôi nghi ngờ rằng đây là một tình huống khá phổ biến, vì cam kết gần đây nhất là lỗi có khả năng bị hỏng nhất, nhưng nếu bạn mất một lần nữa, bạn vẫn có thể sử dụng một phương pháp như thế này, với việc sử dụng cẩn thận git cherrypickvà từ chối trong .git/logs/HEAD.

Khi tôi gặp vấn đề này, tôi đã sao lưu các thay đổi gần đây của mình (vì tôi biết những gì tôi đã thay đổi) sau đó xóa tệp đó, nó đã phàn nàn về .git / location. Sau đó, tôi đã làm một git kéo. Hãy cẩn thận, điều này có thể không làm việc cho bạn.

Tôi gặp phải điều này một khi hệ thống của tôi bị hỏng. Những gì tôi đã làm là thế này:

(Xin lưu ý rằng các cam kết bị hỏng của bạn bị mất, nhưng các thay đổi vẫn được giữ lại. Bạn có thể phải tạo lại các cam kết đó ở cuối quy trình này)

• Sao lưu mã của bạn.
• Đi đến .gitthư mục làm việc của bạn và xóa thư mục.
• Bây giờ sao chép điều khiển từ xa ở một vị trí khác và sao chép .gitthư mục trong đó.
• Dán nó trong thư mục làm việc của bạn.
• Cam kết như bạn muốn.

Chỉ cần xóa thư mục .git và thêm lại. Giải pháp đơn giản này đã làm việc cho tôi.