2010-11-01 23 views
24

Khi tôi đã làm một svn git rebase nó dừng lại tại một thời điểm nói: (. Tôi đến để nhận biết rằng những phím SHA tương ứng với một cây và không phải là một cam kết từ git chương trình của hai phím sha trên)Làm cách nào để giải quyết chỉ mục git-svn không khớp?

Index mismatch: SHA key of a tree != SHA key of another tree.

re-reading <sha index of a commit in svn/trunk> 
... list of files ... 
fatal: bad object <SHA1 index of the bad object> 
rev-list -1 <SHA1 index of the bad object> --not <SHA1 index of the revision it was trying to re-read>: command returned error: 128 

Tôi không có kinh nghiệm trong các hoạt động nội bộ của git, vậy có một chuỗi các bước để làm theo các vấn đề phân tích như thế này và có thể giải quyết chúng?

+3

Việc đầu tiên tôi nghĩ rằng tôi sẽ thử với một kho lưu trữ bị nghi ngờ bị hỏng là một ['git fsck'] (http://www.kernel.org/pub/software/scm/git/docs/git-fsck.html). –

+0

@ Greg-Hewgill: Cảm ơn bạn đã đề xuất. Tôi đã làm một fitk git và nó được liệt kê một loạt các cây lủng lẳng, cam kết và các đốm màu. Tôi đang tham khảo phần này trong hướng dẫn sử dụng Git: http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#recovering-from-repository-corruption và cố gắng tìm ra những gì đã xảy ra trong repo. May mắn thay, vài tuần trở lại tôi đã lưu trữ thư mục .git của tôi để đồng nghiệp của tôi bắt đầu và chạy với repo. Tôi đã sử dụng nó và tạo ra một repo mới và tiếp tục với công việc của tôi trong khi tôi tìm ra những gì đã xảy ra với người bị hỏng. – yasouser

+0

Chỉ có điều mà tôi có thể nghĩ đến là một người khác có thể bị loại bỏ trước khi bạn làm, do đó thay đổi khóa SHA của repo từ xa và cho bạn lỗi mà bạn thấy bây giờ. Nếu bạn đã kéo các thay đổi được thực hiện cho cây, sửa bất kỳ xung đột nào, sau đó rebase từ đó, nó có thể hoạt động bình thường. – g19fanatic

Trả lời

30

Tôi đã gặp lỗi này hai lần và cả hai lần đều giải quyết lỗi bằng cách xóa thư mục svn bên trong thư mục .git.

rm -r .git/svn 

sau đó xây dựng lại các siêu dữ liệu svn với:

git svn fetch 

Bạn có thể sẽ thấy một thông báo dọc theo dòng:

Migrating from a git-svn v1 layout... 
Data from a previous version of git-svn exists, but 
    .git/svn 
    (required for this version (1.7.0.4) of git-svn) does not exist. 
Done migrating from a git-svn v1 layout 

và sau khi (xây dựng lại có thể mất một thời gian đặc biệt trên kho lưu trữ lớn) bạn nên kết thúc với một tấm gương làm việc của kho svn một lần nữa.

+0

+1 để đơn giản; nó thực sự là quá mức cần thiết cho các kho lưu trữ lớn nhưng trong hầu hết các trường hợp, tiết kiệm thời gian tổng thể. –

+0

Chấp nhận điều này như là câu trả lời bởi vì, một đồng nghiệp của tôi chạy vào cùng một vấn đề (chỉ số git index không khớp) ngày hôm nay và chúng tôi có thể phục hồi repo bằng phương pháp được đề xuất ở đây. Kể từ khi repo là rất lớn nó được dùng khá trong khi mặc dù. – yasouser

+0

Mất vài giờ để xây dựng lại dữ liệu chỉ mục svn cho repo 1,2 GB của tôi, nhưng nó đã khắc phục được sự cố. –

0

Tôi đã tự mình gặp lỗi này. Chỉ cần xóa ref, như vậy:

rm .git/refs/remotes/git-svn 

Điều đó sẽ làm rõ lỗi.

+0

Tôi không thể tìm thấy git-svn trong thư mục .git/refs/remotes!?! ?! – yasouser

+1

Xin lỗi, lỗi của tôi. Đó phải là '.git/refs/remotes/git-svn'. –

+0

Tôi không có tệp git-svn trong thư mục .git/refs/remotes!?!?! – yasouser

1

Vấn đề đó là bạn phải làm điều này một cách hệ thống trong trường hợp này:

  • sử dụng git + svn
  • tạo chi nhánh trên svn với chi nhánh
  • merge git-svn để thân cây với các công cụ svn
  • loại bỏ các chi nhánh svn
  • làm một git-svn rebase

Cái gì đó bị thiếu, mọi thứ sụp đổ. Cách duy nhất tôi biết để phục hồi là loại bỏ tất cả svn trong .git và xây dựng lại tất cả mọi thứ. Nó chỉ gây phiền nhiễu và mất một thời gian!

29

Vui lòng không xóa thư mục .git/svn để sửa lỗi này. Nó đòi hỏi bạn phải xây dựng lại tất cả mọi thứ, nó là gây phiền nhiễu, nó sẽ mất một thời gian (đối với kích thước của repo của tôi vài giờ) và nó là không cần thiết.

Tôi đã tìm thấy câu trả lời đúng here và tôi đã bao gồm nó bên dưới.

Từ liên kết:

Bên trong thư mục .git chạy như sau:

$ find . -exec grep -Hin 5b32d4ac2e03a566830f30a702523c68dbdf715b {} \; 
Binary file ./svn/.caches/lookup_svn_merge.db matches 
Binary file ./svn/.caches/check_cherry_pick.db matches 

Bây giờ xóa các khớp svn/.caches từ đầu ra của lệnh đầu tiên

$ rm ./svn/.caches/lookup_svn_merge.db 
$ rm ./svn/.caches/check_cherry_pick.db 

Bây giờ git svn rebase hoặc git svn fetch vào nội dung trái tim của bạn.

+2

Có, tôi đã tìm thấy kỹ thuật này sau. Trong lần thử kế tiếp, tôi chỉ xóa 'cache 'và nó nhanh hơn rất nhiều so với việc xóa' .git/svn'. Quên cập nhật tại đây. Cảm ơn bạn đã đăng câu trả lời của mình. – yasouser

12

Cập nhật git khách hàng và tìm nạp lại svn cuối cùng cam kết sử dụng:

git svn reset -r 12345 
git svn rebase 

sửa đổi svn nơi 12345 vẫn đang hiện hữu.

+1

Điều này làm việc trong trường hợp không quan trọng với thư mục '.caches' thì không. – krlmlr

+1

Đây cũng là phương pháp duy nhất có hiệu quả đối với tôi. –

4

Trong trường hợp của tôi, sự cố là do tác giả svn mới/chưa biết không nằm trong tệp authors của tôi mà git-svn được định cấu hình để sử dụng. Nó báo cáo nó trong đầu ra rằng tôi bỏ qua vài lần đọc đầu tiên:

Index mismatch: <leftsha1> != <rightsha1> 
rereading <anothersha1> 
     ... list of files ... 
Author: <name> not defined in /path/to/authors file 

Vì vậy, điều đó đã cho tôi tên mà tôi bị thiếu và tệp gì để thêm nó nữa (Tôi đã kéo email từ người dùng tổ chức đăng ký của tôi) và đã được mịn thuyền.

0

Tôi đã nhận lỗi này:

Index mismatch: <sha> != <sha> re-reading <sha index of a commit in svn/trunk> ... list of files ... <path> was not found in commit <sha> (r<svn rev>)

Nhìn trong SVN repo vào lịch sử của con đường được báo cáo, tôi thấy việc sửa đổi SVN mà tập tin đã được thêm vào. Nhưng nhìn vào Git tại cam kết tạo ra cho bản sửa đổi đó tôi thấy rằng nó không chứa bất kỳ tập tin!

Tôi nghĩ điều này đã được gây ra bởi một đĩa đầy đủ trước đó. Sau khi thực hiện git svn reset -r trở lại bản sửa đổi của cam kết Git bị hỏng, git svn fetch đã hoạt động tốt trở lại.

Các vấn đề liên quan