为什么可能不会显示移动文件的历史记录，我能做些什么呢？ [英] Why might git log not show history for a moved file, and what can I do about it?

问题描述

我使用 git mv ，使用 git stash 重命名了一些文件，快速浏览HEAD（不改变它）然后执行 git stash pop 以重新获得整个批次。我的举动已经从提交列表中消失了，所以我用 git rm 重新编写了它们，提交消息声称git已经发现重命名是重命名。所以我想没有更多的了。

但现在，提交后，我无法了解移动文件的历史记录！下面是git提到的有关提交的内容：

 〜/ projects％git log --summary 
 commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
作者：brone 
日期：Wed Dec 8 22:37:54 2010 +0000 
 
将R_DebugUI移至运行时
 
删除模式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旧提交>> 
〜/ projects％
  

我现在试图获取其中一个的历史记录移动的文件，所以我可以看看旧版本，但我没有得到任何有用的东西：

 〜/ projects / system / runtime / src％git log --follow --find-copies-harder -M -C R_DebugUI_iOS.m 
 commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
作者：brone 
日期：Wed Dec 8 22:37 ：54 2010 +0000 
 
将R_DebugUI移到运行时
〜/ projects / system / runtime / src％
  

（我也试过它没有 -M ， -C 和 - find-copies-harder ，但无济于事。）

我可以在旧的名称，它在从旧位置删除的位置停止：

 〜/ projects％git log --summary  - follow --find-copies-harder -M -C  -  test / R_DebugUI_iOS.m 
 commit de6e9fa2179ae17ec35a5c368d246f19da27f93a 
作者：brone 
日期：Wed Dec 8 22：37：5 4 2010 +0000 
 
将R_DebugUI移至运行时
 
删除模式100644测试/ R_DebugUI_iOS.m 
 
提交32a22d53c27e260714f759ecb3d3864e38b2e87f 
作者：brone 
日期：12月7日星期二23:52:51 2010 +0000 
 
可以设置调试UI的alpha。 
 
<<<旧版提交>> 
〜/ projects％
  

所以我这次没有完全卡住，但我会不想总是不得不做这种事情。 （我预计会有相当数量的文件在他们的生活中至少移动一次。）

我做错了什么？该文件的旧副本和新副本的98.8％是相同的（166条中有2条已更改）。我的理解是，在这种情况下，git应该能够跟踪文件，因为它推断重命名操作而不是明确地存储它们，并且这些文件足够相似，我相信它应该认为它们是相同的。

有什么我可以解决这个问题吗？

解答方案

回答我自己的问题，因为我已经设法减轻我的顾虑，即使我没有完全解决我的问题。 （ git log --follow ）对我来说仍然不起作用。）

首先， - summary 重命名提交日志包含带有文件旧名称的 delete 行。所以如果很容易发现，你可以从那里找到它的旧名称和 git log 。

如果它是零件的一些大的提交，因此有点难以发现 - 这种情况是我的担心之一 - git blame -C 可以与文件的新名称一起使用第一次重命名修订。推测来自原始文件的行仍然存在！ - 所以git应该找到他们的源代码，并显示旧的文件名（以及一个提交散列以获得更好的效果）。然后你可以用 git log 来获取路径。

所以，如果你对历史有一些兴趣该文件作为一个单元（无论出于何种原因），那么它似乎可以做得相对简单。虽然我觉得git会更喜欢你正确使用它。

I've renamed a couple of files using git mv, used git stash, had a quick look at HEAD (without changing it) then did git stash pop to get the whole lot back again. My moves had disappeared from the commit list, so I redid them with git rm and the commit message claimed git had spotted the rename was a rename. So I thought no more of it.

But now, post-commit, I can't get at the history of the moved files! Here's what git says about the commit in question:

~/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%

I'm now trying to get the history of one of these moved files, so I can look at an old version, but I don't get anything very useful:

~/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% 

(I've also tried it without -M, -C and --find-copies-harder, but to no avail.)

I can get its history under its old name, which stops at the point it was deleted from its old location:

~/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%

So I'm not completely stuck this time, but I wouldn't fancy having to do this kind of thing all the time. (I anticipate having a fair number of files that will move at least once in their life.)

Am I doing something wrong? The old copy of the file and the new copy are 98.8% the same (2 lines out of 166 changed). My understanding is that git should be able to track the file in this case, because it infers rename operations rather than storing them explicitly, and the files are similar enough that I believe it should consider them the same.

Is there anything I can do to fix this?

解决方案

Answering my own question, since I have managed to assuage my concerns, even if I haven't solved my problem exactly. (git log --follow still doesn't work for me, though.)

Firstly, the --summary log for the renaming commit includes the delete line with the file's old name. So if it's easy to spot, you can find its old name and git log from there.

If it's part of some large commit, and therefore a bit harder to spot -- and this situation was one of my worries -- git blame -C can be used with the file's new name on the first post-rename revision. Presumably lines remain from the original file! -- so git should find their source, and show old file name (and a commit hash for good measure). You can then pick up the trail with git log.

So, if you have some interest in the history of the file as a unit (for whatever reason) then it seems like it can be done relatively straightforwardly. Though I get the impression git would prefer that you used it properly.

这篇关于为什么可能不会显示移动文件的历史记录，我能做些什么呢？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！