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 deletingvc-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 togit-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
tolog
, sincediff
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 simplegit.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 isO(size of repository)
instead ofO(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 alog.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?
精彩评论