开发者

Can Emacs display entire git history of a file without requiring git.el?

My project underwent multiple directory renames and directory splitting. gitk deals with that very nicely and is capable of tracking a file from head to all file revisions down to the very first one.

Emacs, however, seems to stumble upon the first rename. It only lists a few recent revisions when doing Ctrl-x v l (Tools > Version Control > Show History on the menu, vc-git-print-log function in 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 

Since I am开发者_开发知识库 used to the way Emacs built-in support for Version Control works (finger habits from the CVS days...), I wonder whether it is possible to enable it to track the entire revision history, despite the renames, just as gitk does, without using a completely different package?


You have other packages for integrating git with Emacs, as described here (maggit, git-emacs or egg, an old fork from maggit).

What you need to check, in git.el or in those other implementation, is how they implement git log:
Only a git log -M -C will find renames and copies of a file(*) (or at least a git log --follow).
(Also, check your git version)

(*): Not exactly for one file: --follow is the right option when displaying the log for one file. See the last part of this answer to know why.

That being said, without changing anything to your current package, you can check your local git config, and try:

git config diff.renames copies

and see if that changes the default git.el log result.


The OP WinWin reports:

  • the --follow is the right option use for rename and copy detection for one given file.
  • that modifying C:\emacs-23.2\lisp\vc-git.el (and deleting vc-git.elc in same folder, this is important!), adding "--follow" to the (defun vc-git-print-log ... part is enough for said option to be active.

Note: to understand the difference between -C and -M options, and --follow, see this thread

Jakub Narębski mentioned in May 2010 (and that still seems accurate in July 2011):

'-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'?

I don't think so. Note also that '--follow' works only with single file, and does not work for example (currently) with directory pathspec.

To which, Eli Barzilay adds:

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 answers:

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).


About the config settings, Jeff King mentions:

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?

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜