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

[Nicolás Ojeda Bär]

Dear Dmitry,

Apologies for the delay in getting back to you; I have been submerged
in my day job and haven't had any time to look at the code again (the
copyright assignment is done, by the way).

I read your message, and I think immitating GitHub's UI is a great
idea, as it liberates us from having to do any kind of "pretreatment"
of the git log (which can be expensive for large repos).

We should focus in this direction to fix this issue. If I get some
spare time over the holidays I will try to take a look (sadly, I
cannot promise that will be the case...).

Cheers,
Nicolas

On Mon, Dec 12, 2022 at 12:02 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> 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.