Tại sao git log không hiển thị lịch sử cho một tệp đã di chuyển và tôi có thể làm gì với nó?

Question

Tôi đã đổi tên một vài tệp bằng cách sử dụng git mv, được sử dụng git stash, đã xem nhanh HEAD (không thay đổi) sau đó đã làm git stash pop để nhận lại toàn bộ lô. Chuyển động của tôi đã biến mất khỏi danh sách cam kết, vì vậy tôi redid chúng với git rm và thông báo cam kết tuyên bố git đã phát hiện ra tên đã được đổi tên. Vì vậy, tôi không nghĩ nhiều hơn về nó.

Nhưng giờ đây, sau cam kết, tôi không thể xem lịch sử của các tệp đã di chuyển! Dưới đây là những gì git nói về cam kết được đề cập:

~/projects% git log --summary 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 

delete mode 100644 test/R_DebugUI_iOS.h 
delete mode 100644 test/R_DebugUI_iOS.m 
create mode 100644 system/runtime/src/R_DebugUI_iOS.h 
create mode 100644 system/runtime/src/R_DebugUI_iOS.m 

<<snip older commits>> 
~/projects% 

Tôi đang xem lịch sử của một trong các tệp đã chuyển này, vì vậy tôi có thể xem phiên bản cũ, nhưng tôi không nhận được gì hữu ích:

~/projects/system/runtime/src% git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 
~/projects/system/runtime/src% 

(tôi cũng đã thử nó mà không -M, -C và --find-copies-harder, nhưng vô ích.)

tôi có thể nhận lịch sử của mình theo tên cũ của nó, mà dừng lại tại điểm đó là đã bị xóa khỏi vị trí cũ của nó:

~/projects% git log --summary --follow --find-copies-harder -M -C -- test/R_DebugUI_iOS.m 
commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
Author: brone 
Date: Wed Dec 8 22:37:54 2010 +0000 

    Moved R_DebugUI into runtime 

delete mode 100644 test/R_DebugUI_iOS.m 

commit 32a22d53c27e260714f759ecb3d3864e38b2e87f 
Author: brone 
Date: Tue Dec 7 23:52:51 2010 +0000 

    Can set debug UI's alpha. 

<<snip older commits>> 
~/projects% 

Vì vậy, tôi không hoàn toàn bị mắc kẹt lần này, nhưng tôi không muốn làm điều này mọi lúc. (Tôi dự đoán có một số lượng tệp hợp lý sẽ di chuyển ít nhất một lần trong cuộc sống của họ.)

Tôi có làm gì sai không? Bản sao cũ của tập tin và bản sao mới là 98,8% giống nhau (2 dòng trong số 166 thay đổi). Sự hiểu biết của tôi là git sẽ có thể theo dõi tệp trong trường hợp này, bởi vì nó xâm nhập các hoạt động đổi tên thay vì lưu trữ chúng một cách rõ ràng, và các tệp tương tự đủ để tôi tin rằng nó nên xem xét chúng giống nhau.

Tôi có thể làm gì để sửa lỗi này không?

Answer 1

Trả lời câu hỏi của riêng tôi, vì tôi đã cố gắng làm dịu bớt mối quan tâm của tôi, ngay cả khi tôi đã không giải quyết vấn đề của tôi chính xác. (git log --follow vẫn không hoạt động đối với tôi).

Trước hết, nhật ký --summary cho cam kết đổi tên bao gồm dòng delete với tên cũ của tệp. Vì vậy, nếu dễ dàng phát hiện ra, bạn có thể tìm thấy tên cũ và git log từ đó.

Nếu đó là một phần của một số cam kết lớn, và do đó khó hơn một chút - và tình huống này là một trong những lo lắng của tôi - git blame -C có thể được sử dụng với tên mới của tệp trên bản sửa đổi sau đổi tên đầu tiên. Có lẽ dòng vẫn còn từ tập tin gốc! - Vì vậy git nên tìm nguồn của họ, và hiển thị tên tập tin cũ (và một băm cam kết cho biện pháp tốt). Sau đó, bạn có thể chọn đường nhỏ với git log.

Vì vậy, nếu bạn có chút quan tâm đến lịch sử của tệp dưới dạng đơn vị (vì bất kỳ lý do gì) thì có vẻ như nó có thể được thực hiện tương đối đơn giản. Mặc dù tôi nhận được ấn tượng git thích rằng bạn sử dụng nó đúng cách.

Answer 2

Vâng, tôi thấy lại tên của tôi với git log -M --summary ..

Answer 3

Vui lòng thử với git log --follow trên tệp của bạn. Tôi học hỏi từ đây Is it possible to move/rename files in git and maintain their history?

Answer 4

git log --follow ./path/to/file 

Tôi tin rằng đây là những gì bạn đang tìm kiếm.