GNU bug report logs -
#55871
27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames
Previous Next
Reported by: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Date: Thu, 9 Jun 2022 14:33:03 UTC
Severity: normal
Tags: patch
Found in version 27.1
Fixed in version 30.1
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
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.
This bug report was last modified 1 year and 195 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.