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

Question

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 <[email protected]>
Date:   Tue Jul 12 18:17:27 2011 -0600

    commit comment 

commit 0b52ca957a79a26e51bdd6f7193ef913c4abdc7b
Author: WinWin <[email protected]>
Date:   Tue Jul 10 10:39:12 2011 -0600

    commit comment 

commit 8ca577e532849203646867527921b66aa1162dbd
Author: WinWin <[email protected]>
Date:   Tue Jul 10 08:01:59 2011 -0600

    commit comment 

commit 9e623a23ad485d0937fe5409162f07434be8ca63
Author: WinWin <[email protected]>
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?

Answer 1

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?