bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames)

[Dmitry Gutov <dgutov@yandex.ru>]

On 18/08/2022 05:10, Dmitry Gutov wrote:
> I experimented with --follow myself in the past, and it is annoying in 
> that it skips commits, some of which are visible in the log when you 
> don't use --follow, details here: 
> https://stackoverflow.com/questions/46487476/git-log-follow-graph-skips-commits
> 
> So I figured the approach in (3) has something to do with it. But it 
> seems not to be the case.

I've tried another idea: to pre-process the file's history and pass all 
historical file names to 'git log' inside vc-git-print-log.

Unfortunately, that delays the appearance of the log significantly. In 
the Emacs repo that comes down to several seconds, which seems 
unacceptable. But that would fix both the problems with a/f/d and the 
bug described in the SO question above.

Looking around for how other software deals with it, it seems GitHub has 
found a satisfactory solution which adds a new UI element with basically 
zero performance cost.

At first it was implemented in a Chrome extension for it 
(https://github.com/jeffstieler/github-follow-extension), but then added 
to the core functionality this summer 
(https://github.blog/changelog/2022-06-06-view-commit-history-across-file-renames-and-moves/).

This gif shows the workflow: 
https://i0.wp.com/user-images.githubusercontent.com/4021812/171795153-4f327a04-eb27-4d46-acb1-73d2e82ce4c5.gif?ssl=1

We should be able to do something similar.

Step 1: Drop the '--follow' argument in all cases.

Step 2: After the log is finished printing, we detect somehow that the 
last commit was a rename one. Perhaps using an additional process call, 
or perhaps by adding some output to the process which we'll hide through 
font-lock or process filter. When it is a rename, we print a message at 
the end, saying the file has been renamed. And a button saying e.g. 
"Print Previous Log", which would print the history for the previous 
name. That history should also include the missing commits from the SO 
question.

Not sure how to deal with duplicating file names best (like etc/NEWS has 
been the name of many files in the Emacs repo): either limiting the 
first revision to start from -- but that keep bring back the missing 
commit problem, oh well -- or some other way.

Can't exactly check what GitHub is doing, because they don't actually 
provide this for NEWS.24, guess because it was not a straight rename: 
https://github.com/emacs-mirror/emacs/commits/master/etc/NEWS.24

But

   git log -M50% -C --stat 5f8947c7007d1d8 -n 1

at least detects it as a copy if not a rename. Guess they didn't adopt 
the whole follow-renames logic, and we can do better.

I don't have any code to show, but it shouldn't require too many changes.