git - Emacs 可以在不需要 git.el 的情况下显示文件的完整 git 历史记录吗？

Question

我的项目经历了多次目录重命名和目录拆分。 gitk 处理得很好，并且能够跟踪文件从头到所有文件修订一直到第一个文件。

然而，Emacs 似乎偶然发现了第一个重命名。它仅在执行 Ctrl-x v l 时列出一些最近的修订(Tools > Version Control > Show History 在菜单上，vc-git-print-log vc-git.el 中的函数:

commit 13172930ab094badeab81cd2e05119d2a4c1f58a
Author: WinWin <winwin@example.com>
Date:   Tue Jul 12 18:17:27 2011 -0600

    commit comment 

commit 0b52ca957a79a26e51bdd6f7193ef913c4abdc7b
Author: WinWin <winwin@example.com>
Date:   Tue Jul 10 10:39:12 2011 -0600

    commit comment 

commit 8ca577e532849203646867527921b66aa1162dbd
Author: WinWin <winwin@example.com>
Date:   Tue Jul 10 08:01:59 2011 -0600

    commit comment 

commit 9e623a23ad485d0937fe5409162f07434be8ca63
Author: WinWin <winwin@example.com>
Date:   Tue Jul 10 01:50:39 2011 -0600

    commit comment 

由于我已经习惯了 Emacs 内置 支持版本控制的工作方式(CVS 时代的手指习惯......)，我想知道是否可以启用它来跟踪整个修订历史，尽管重命名，就像 gitk 一样，没有使用完全 different package ？

Answer 1

你还有其他packages for integrating git with Emacs , 作为 described here ( maggit 、 git-emacs 或 egg ，来自 maggit 的旧 fork )。

在 git.el 或其他实现中，您需要检查的是它们如何实现 git log :
只有一个git log -M -C将find renames and copies of a file^(*) (或至少一个 git log --follow )。
(另外，check your git version)

^{(*):不完全适用于 one 文件:--follow 是显示 one 文件日志时的正确选项。请参阅此答案的最后部分以了解原因。}

话虽这么说，但无需对当前包进行任何更改，您可以检查本地 git config ，然后尝试:

git config diff.renames copies

看看这是否改变了默认值 git.el log结果。

---

OP WinWin报告:

• --follow是对一个给定文件进行重命名和复制检测的正确选项。
• 那个修改C:\emacs-23.2\lisp\vc-git.el (并删除同一文件夹中的vc-git.elc，这很重要!)，将“--follow”添加到(defun vc-git-print-log ...部分足以使所述选项处于事件状态。

---

注意:了解-C之间的区别和 -M选项，和 --follow , 请参阅 this thread

Jakub Narębski 2010 年 5 月提到(2011 年 7 月似乎仍然准确):

'-M/-C' is useful with "git diff" without pathspec, including e.g. "git show -C".

The problem with "git log -M -- <filename>" is that history simplification, which is required for good performance, happens before diff mechanism has a chance to perform rename detection. Before there was '--follow' option to git-log (which supports only the case of single file, and doesn't work that well with more complicated history), you were forced to do:

$ git log -M -- <filename> <oldname> <oldername>...

Also, is there a way to set this as the default for 'git log'?

我不这么认为。还要注意 ' --follow ' 仅适用于单个文件，例如(当前)不适用于目录 pathspec。

Eli Barzilay添加:

OK, so just to clear this up:
-C and -M (and --find-copies-harder) are for 'diff', and --follow is for 'log' with a single file (and each will pass it on to the other)?

Jeff King答案:

Yes (well, diff can never pass --follow to log, since diff never invokes log, but yes, the per-commit diff shown by log uses the -C and -M given to log).

---

关于配置设置，Jeff King 提到:

copy detection can be really* slow. There is a reason it isn't on by default.
Try "git log -1000 -p" versus "git log -1000 -p -C -M --find-copies-harder" in some repository.
In a simple git.git test, it is almost 5x slower (about 1 second versus 5 seconds on my machine).
For large repositories, it can be much worse, because now each diff is O(size of repository) instead of O(size of changes).

Still, I see your point that you might want it on all the time, if you have a sufficiently small repo. There is "diff.renames" to turn on rename detection all the time.
But I think a log.follow option doesn't make sense at this point:

$ git config log.follow true
$ git log foo.c ;# ok, follow foo.c
$ git log foo.c bar.c ;# uh oh, now what?

Does the last one just barf, and make you say "git log --no-follow foo.c bar.c"?
Does it quietly turn off --follow, making the user guess why "git log foo.c" finds some history that "git log foo.c bar.c" doesn't?