GNU bug report logs - #55871
27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames

Previous Next

Package: emacs;

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>, 55871 <at> debbugs.gnu.org
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
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.