GNU bug report logs -
#8756
23.3; vc-git.el doesn't use --follow argument in vc-git-print-log
Previous Next
Reported by: Steinar Bang <sb <at> dod.no>
Date: Sun, 29 May 2011 20:28:01 UTC
Severity: normal
Tags: fixed
Merged with 19045
Found in versions 23.3, 25.0.50
Fixed in version 26.1
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #53 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
How are you gentlemen,
Following renames is nice no matter what Git upstream thinks,
so I gave this bug a try. I'd like to share some progress.
Diffing (`d`), paging (`f`) and annotating a file (`a`) revision works.
I've tested it with Git version 1.8.5.4 and 2.0.2.
Parallel git log with hash/file information is run when
a log is queried. (vc-git-file-shalist) provides access to
a list of SHA1's/historical file names for the file open
in the *vc-change-log* buffer.
The bad part is that whole-changeset (`D`) diffing is broken
(wrong revisions are selected for diff).
The culprit is `vc-git-previous-revision`.
Using HASH^ to obtain the parent of HASH revision produces
unexpected results when file renames are involved. However,
for whole-changeset diffing HASH^ seems to be exactly what
we need. However, `vc-git-previous-revision` doesn't seem
to enable any inspection of the context in which we use it
(in other words, if we hit `d` or `D` in the log buffer.)
Any ideas?
I also have not tackled revision navigation in the annotation
mode, but this can likely be solved by plugging calls to
`(vc-git-rev-to-filename)` somewhere in the annotation mode.
[vc-git-follow-renames.patch (text/x-diff, attachment)]
This bug report was last modified 5 years and 198 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.