[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do no
From: |
Dmitry Gutov |
Subject: |
bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames) |
Date: |
Mon, 12 Dec 2022 01:02:45 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 |
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.
- bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames),
Dmitry Gutov <=