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

[Dmitry Gutov <dmitry@gutov.dev>]

Version: 30.1

On 14/12/2023 03:23, Dmitry Gutov wrote:
> 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.

Feedback is still welcome, but I have now pushed a revised version to 
master (5b80894d0a7), so marking this as resolved.