Subject: Re: bug#39044: 27.0.50; On git log-view-diff does not work for moved files.

From: Dmitry Gutov <[email-masked]>
Date: Thu, 14 Dec 2023 03:23:35 +0200

On 13/05/2020 04:36, Dmitry Gutov wrote:
> On 08.01.2020 22:48, David Koppelman wrote:
>>
>> With (setq vc-git-print-log-follow t) visit a file in a git repo that
>> was moved from some other directory and which had changes when in that
>> other directory. Start log view, C-x v =, move the cursor to a commit
>> made in the file's former location, and press d (log-view-diff). Rather
>> than showing a diff, a message reporting no changes is shown.
> 
> I usually give up and press 'D' in those cases (diff for the whole tree).
> 
>> This flaw was noted in bug 8756, covering vc-diff/log-view, but was
>> left to a follow on bug.
>> (https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756).
>>
>> Interestingly, vc-annotate has no trouble with renames. See
>> commit d1e4c4037e88f3256db19813805d03f8ad0291fa.
> 
> vc-annotate is fine because 'git blame' includes the previous file name 
> in the output. Not so for 'git log' by default.
> 
> Looking at this issue for some time, I haven't found an easier way to do 
> this rather than:
> 
> 1. When vc-git-print-log-follow=t, also add the --name-status argument 
> to the command invocation.
> 
> 2. Hide this new text from the user using font lock by adding some rules 
> to vc-git-log-view-mode.
> 
> 3. _Probably_ teach log-view-current-file how to determine the current 
> file name. _Maybe_ via log-view-file-re. Some come would also need to 
> set log-view-per-file-logs to t for per-file Git logs. It could also be 
> made into a backend method instead.
> 
> See also bug#13004 for the same problem when using Hg. It could use the 
> same approach, but the solution is more questionable since '--stat' 
> seems to noticeably slow it down.

I have now posted a somewhat related solution to 
https://debbugs.gnu.org/55871#41.

Except it requires vc-git-print-log-follow to be disabled, and has 
virtually no runtime overhead. And it works when a fileset contains 
several files, not just for singles (a rare case, though).

Feedback welcome.

And maybe these bug reports should be merged, actually, since the 
complaint is more or less the same.