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

[Dmitry Gutov]

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.