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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 55871 in the body.
You can then email your comments to 55871 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1;
 vc-git.el log view 'a', 'f', 'd' do not work when following renames
Date: Thu, 9 Jun 2022 11:54:44 +0200

When pressing 'C-x v l' in a git versioned file that has been renamed,
it is possible to get a full history (ie including renames) by setting
'vc-git-print-log-follow' to t.

However, if doing this, the functions

- 'd' (log-view-diff)
- 'f' (log-view-find-revision)
- 'a' (log-view-annotate-revision)

stop working with revisions "before" the rename. There is a previous
discussion of this problem in

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756

but the discussion ends by suggesting to open a new bug report about
this issue, which I am doing here.

In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-21 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.22000
System Description: Microsoft Windows 10 Pro (v10.0.2009.22000.708)

Recent messages:
process
Mark saved where search started
Saving file c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf...
Mark set
Wrote c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf
Wrote c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf (3
pending errors, use C-c C-x to jump)
Mark saved where search started [3 times]
Mark set
Mark saved where search started [13 times]
Quit [2 times]
Quit
Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: cp1252

Major mode: caml

Minor modes in effect:
  shell-dirtrack-mode: t
  merlin-mode: t
  save-place-mode: t
  winner-mode: t
  savehist-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  display-time-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/cygwin64/home/nojebar/mlfi/mlfi-ins/share/emacs/site-lisp/ocp-indent
hides ~/scripts/install/emacs/ocp-indent
c:/cygwin64/home/nojebar/.emacs.d/elpa/jsonrpc-1.0.15/jsonrpc hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/jsonrpc
c:/cygwin64/home/nojebar/.emacs.d/elpa/xref-1.4.1/xref hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/xref
c:/cygwin64/home/nojebar/.emacs.d/elpa/project-0.8.1/project hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/project
c:/cygwin64/home/nojebar/.emacs.d/elpa/flymake-1.2.2/flymake hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/flymake
c:/cygwin64/home/nojebar/.emacs.d/elpa/seq-2.23/seq hides c:/Program
Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/seq
c:/cygwin64/home/nojebar/.emacs.d/elpa/eldoc-1.12.0/eldoc hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/eldoc
~/scripts/install/emacs/cl-lib hides c:/Program
Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/cl-lib

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils add-log log-view pcvs-util
help-fns radix-tree vc-annotate ffap grep thingatpt cl-extra help-mode
shell pcomplete smerge-mode diff vc vc-dispatcher misearch multi-isearch
merlin-xref xref project merlin-cap merlin pcase caml-types crm caml
advice rx compile derived imenu cygwin-mount ange-ftp comint ansi-color
ocamlformat ocp-indent caml-font vc-git diff-mode easy-mmode dired-x
dired dired-loaddefs saveplace edmacro kmacro winner ring savehist paren
delsel time autorevert filenotify info proof-site proof-autoloads
package easymenu browse-url url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 298590 19356)
 (symbols 48 12729 1)
 (strings 32 40782 1936)
 (string-bytes 1 1406019)
 (vectors 16 22528)
 (vector-slots 8 276819 12620)
 (floats 8 104 554)
 (intervals 56 42748 0)
 (buffers 1000 42))

Message #8 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
To: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Fri, 10 Jun 2022 19:31:55 +0200

[Message part 1 (text/plain, inline)]

Dear all,

Attached is a patch that solves some of the problems in this issue (not all).

Its main feature is that it should not modify anything if you are not
using `vc-git-print-log-follow`.

If you are, the patch makes it possible to use `a`, `f` and `d` from
inside the `*vc-change-log*` buffer.

The patch itself is very much based on the one proposed in
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#53, with some
changes to make sure that nothing changes if `vc-git-print-log-follow`
is not being used. Additionally, a horrible HACK (see commit message)
is used to allow `vc-git.el` to discriminate between `d` and `D` in
the `*vc-change-log*` buffer, as these two functions require different
Git commands to be executed when following renames (this is also
discussed in the just linked bug report).

Cheers,
Nicolas

[0001-vc-git.el-better-support-for-follow-mode.patch (application/octet-stream, attachment)]

Message #13 received at 55871 <at> debbugs.gnu.org (full text, mbox):

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: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Thu, 18 Aug 2022 05:10:16 +0300

Hi Nicholas,

On 10.06.2022 20:31, Nicolás Ojeda Bär wrote:
> Dear all,
> 
> Attached is a patch that solves some of the problems in this issue (not all).
> 
> Its main feature is that it should not modify anything if you are not
> using `vc-git-print-log-follow`.
> 
> If you are, the patch makes it possible to use `a`, `f` and `d` from
> inside the `*vc-change-log*` buffer.
> 
> The patch itself is very much based on the one proposed in
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756#53, with some
> changes to make sure that nothing changes if `vc-git-print-log-follow`
> is not being used. Additionally, a horrible HACK (see commit message)
> is used to allow `vc-git.el` to discriminate between `d` and `D` in
> the `*vc-change-log*` buffer, as these two functions require different
> Git commands to be executed when following renames (this is also
> discussed in the just linked bug report).

Thanks for your help with updating this patch. I've tried it out, and it 
seems functional, which is great.

First of all, how do you feel about signing copyright assignment for 
Emacs? AFAICT you haven't done so yet, and this patch borders on our 
allowed limit without assignment (if I take only the lines that changed 
substantially from Dmitry Dzhus's version). It would probably be easier 
to get the assignment going anyway, so you continue to be able to 
contribute.

There are also a few of improvements I'm eyeing here (not requirements 
for acceptance -- I can do them myself, if you like):

1) vc-git--shalist-raw doesn't seem to serve much of a purpose. It is 
there only to delay the conversion from the raw string into a list?

2) It would be better to produce shalist entirely lazily. I'm not sure 
what's stopping us from doing that, given that vc-git--shalist knows how 
to find the log buffer. Finding the values for all the arguments might 
be a problem, so we can save the args (start-revision, limit) to a new var.

3) git-log-view-diff-whole-changeset might be unnecessary. vc-git-diff 
could look up two file names, for both revisions (the current and the 
one corresponding to the previous revision in the sha list), or 
log-view-diff-common could pass explicitly the previous revision from 
the already-printed list, rather than fetch it using (vc-call-backend 
log-view-vc-backend 'previous-revision nil fr) -- I'm not sure why it's 
doing it this way.

At first I just changed vc-git-diff to do this:

    (let ((file1 (vc-git--rev-to-filename rev1))
          (file2 (vc-git--rev-to-filename rev2)))
      (when (or file1 file2)
        ;; Run diff from the repository root because our file names are
        ;; relative to it
        (setq default-directory (vc-git-root default-directory))
        (when file1 (push file1 files))
        (when file2 (push file2 files))))

...and reverted the change to vc-git-previous-revision, and that almost 
worked, except a revision that did rename only showed one side 
(addition, not deletion).

WDYT?

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.

Message #16 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 55871 <at> debbugs.gnu.org,
 Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Subject: Re: bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work
 when following renames
Date: Tue, 06 Sep 2022 12:56:20 +0200

Dmitry Gutov <dgutov <at> yandex.ru> writes:

> First of all, how do you feel about signing copyright assignment for
> Emacs? 

This was a couple of weeks ago, but there wasn't any followup as far as
I can tell.

Nicolás, would you be OK with assigning copyright to the FSF?

Message #21 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55871 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work
 when following renames
Date: Tue, 6 Sep 2022 14:12:21 +0200

Hello,

Sorry for the delay in getting back to you. No problem with assigning
copyright to FSF.

I will reply to Dmity separately.

Cheers,
Nicolas


On Tue, Sep 6, 2022 at 12:56 PM Lars Ingebrigtsen <larsi <at> gnus.org> wrote:
>
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
> > First of all, how do you feel about signing copyright assignment for
> > Emacs?
>
> This was a couple of weeks ago, but there wasn't any followup as far as
> I can tell.
>
> Nicolás, would you be OK with assigning copyright to the FSF?
>

Message #24 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Cc: 55871 <at> debbugs.gnu.org, Dmitry Gutov <dgutov <at> yandex.ru>
Subject: Re: bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work
 when following renames
Date: Tue, 06 Sep 2022 14:13:37 +0200

Nicolás Ojeda Bär <n.oje.bar <at> gmail.com> writes:

> Sorry for the delay in getting back to you. No problem with assigning
> copyright to FSF.

Great; here's the form to get started:


Please email the following information to assign <at> gnu.org, and we
will send you the assignment form for your past and future changes.

Please use your full legal name (in ASCII characters) as the subject
line of the message.
----------------------------------------------------------------------
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]
Emacs

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]

Message #29 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work
 when following renames
Date: Sat, 3 Dec 2022 04:02:23 +0200

Hi Nicholas,

On 06/09/2022 15:12, Nicolás Ojeda Bär wrote:
> Sorry for the delay in getting back to you. No problem with assigning
> copyright to FSF.
> 
> I will reply to Dmity separately.

How's progress with the copyright assignment or the additional reply? If 
you got the ball rolling, we can continue the discussion now.

If you hit some problems (with your employer or etc), I was thinking of 
try an alternative patch based on the 2014 one (which has its copyright 
assigned).

Or if maybe you have something newer to share, please do.

Message #32 received at 55871 <at> debbugs.gnu.org (full text, mbox):

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: Re: 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.

Message #35 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Mon, 12 Dec 2022 17:44:27 +0100

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 <at> 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.

Message #38 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Tue, 13 Dec 2022 03:23:29 +0200

Dear Nicolas,

On 12/12/2022 18:44, Nicolás Ojeda Bär wrote:

> 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).

Good to hear about the copyright assignment.

No problem about delayed replies, I first of all wanted to experiment 
with an alternative and see how others deal with it.

> 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).

Indeed. I suppose we'll lose out in some more complex cases (e.g. if 
--follow tracks copies, it might track the cases when several files had 
been copied into one, including when that action spanned several 
commits; and thus --follow could show the history of each such file), 
but we should win in the most common cases (single-file copies and 
renames) OOtB, which we don't have any good support for still.

> 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...).

We won't be able to put the improvement into Emacs 29 anyway (the 
release branch has been cut, it's now bugfix-only), so there is no hurry.

Let's see who gets to this first. If you wanted to finish up your patch 
instead, I'm not going to say no either. But GitHub's approach seems 
like it should require less (and less complex) code.

Best,
Dmitry.

Message #41 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Thu, 14 Dec 2023 02:52:23 +0200

[Message part 1 (text/plain, inline)]

On 13/12/2022 03:23, Dmitry Gutov wrote:
>> 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).
> 
> Indeed. I suppose we'll lose out in some more complex cases (e.g. if 
> --follow tracks copies, it might track the cases when several files had 
> been copied into one, including when that action spanned several 
> commits; and thus --follow could show the history of each such file), 
> but we should win in the most common cases (single-file copies and 
> renames) OOtB, which we don't have any good support for still.
> 
>> 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...).
> 
> We won't be able to put the improvement into Emacs 29 anyway (the 
> release branch has been cut, it's now bugfix-only), so there is no hurry.
> 
> Let's see who gets to this first. If you wanted to finish up your patch 
> instead, I'm not going to say no either. But GitHub's approach seems 
> like it should require less (and less complex) code.

Attached is the implementation for this alternative approach.

It's Git-only, but otherwise seems to function well (with potential for 
future additions). The look of the message and the button could use some 
work, but this is the best I came up thus far.

As far as testing, it allowed following all files in Emacs's repo (that 
I have tried) to their original creation. Including etc/NEWS.29, and 
most other NEWS.*, with NEWS.28 being an exception (apparently because 
on that occasion NEWS was truncated before NEWS.28 was created).

Also important: set vc-git-print-log-follow to nil. Otherwise logs don't 
end on renames, and this feature doesn't get a chance to work.

Cheers,
Dmitry.

[vc-git-file-name-changes.diff (text/x-patch, attachment)]

Message #44 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Thu, 14 Dec 2023 03:23:05 +0200

On 14/12/2023 02:52, Dmitry Gutov wrote:
> but otherwise seems to function well (with potential for future additions)

To clarify: this version only makes 'd' work (not 'f' or 'a'), but the 
other two are fixed more easily.

Message #47 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Nicolás Ojeda Bär <n.oje.bar <at> gmail.com>
Cc: 55871 <at> debbugs.gnu.org
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 04:01:59 +0200

[Message part 1 (text/plain, inline)]

On 14/12/2023 03:23, Dmitry Gutov wrote:
> On 14/12/2023 02:52, Dmitry Gutov wrote:
>> but otherwise seems to function well (with potential for future 
>> additions)
> 
> To clarify: this version only makes 'd' work (not 'f' or 'a'), but the 
> other two are fixed more easily.

Attached is the new revision with combined fix.

[vc-git-file-name-changes-v2.diff (text/x-patch, attachment)]

Message #50 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 55871 <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
Subject: Re: bug#55871: Acknowledgement (27.1;
 vc-git.el log view 'a', 'f', 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 15:05:04 +0200

> Cc: 55871 <at> debbugs.gnu.org
> Date: Fri, 15 Dec 2023 04:01:59 +0200
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> On 14/12/2023 03:23, Dmitry Gutov wrote:
> > On 14/12/2023 02:52, Dmitry Gutov wrote:
> >> but otherwise seems to function well (with potential for future 
> >> additions)
> > 
> > To clarify: this version only makes 'd' work (not 'f' or 'a'), but the 
> > other two are fixed more easily.
> 
> Attached is the new revision with combined fix.

FYI: 'd' and 'f' work with bzr without any changes.  'a' doesn't work
(evidently, "bzr annotate -r REVISION FILE" doesn't work when FILE did
not exist in REVISION, but was renamed by a later revision, and one
needs to run "bzr status -Sr REVISION" and look for the "renamed"
report in the result, which will then provide the previous name).

(FTR: I used src/unexcoff.c file to test this.)

> +*** Support for viewing file change history across renames.
> +When a fileset's VC change history ends at a rename, we now print the
> +old name(s) and a button which jumps to their history.  Only supported
> +with Git at the moment.

I think this should at least tell that for files under Bazaar, the VC
change history will always include the renames.  Looks like Mercurial
is in the same department as Git?  If so, I think the text should say
that this is not supported for Mercurial yet, and that Bazaar shows
the entire history, including renames, by default.  Or something like
that.

I also think this entry should mention the relevant VC commands
("C-x v l" and what else?), since otherwise "VC change history"
is not concrete enough to tell users which command(s) is/are affected.

Thanks.

Message #53 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55871 <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 16:39:04 +0200

On 15/12/2023 15:05, Eli Zaretskii wrote:
>> Cc: 55871 <at> debbugs.gnu.org
>> Date: Fri, 15 Dec 2023 04:01:59 +0200
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>> On 14/12/2023 03:23, Dmitry Gutov wrote:
>>> On 14/12/2023 02:52, Dmitry Gutov wrote:
>>>> but otherwise seems to function well (with potential for future
>>>> additions)
>>>
>>> To clarify: this version only makes 'd' work (not 'f' or 'a'), but the
>>> other two are fixed more easily.
>>
>> Attached is the new revision with combined fix.
> 
> FYI: 'd' and 'f' work with bzr without any changes.

To my understanding, Bazaar doesn't really exist in this day and age, so 
should we pay extra attention to it in this NEWS entry?

We could say that the problem is relevant to Git and Hg, and the current 
solution only helps Git. I'm not sure what's the best phrasing, however, 
which won't bloat the NEWS entry too much.

Though by the time 30 is released someone might implement the 
'file-name-changes' handler for Hg too: it might be easy enough with the 
rest of the solution already in place. One will have to see whether Hg 
has any special caveats, though, like the one you noted for Bzr below.

> 'a' doesn't work
> (evidently, "bzr annotate -r REVISION FILE" doesn't work when FILE did
> not exist in REVISION, but was renamed by a later revision, and one
> needs to run "bzr status -Sr REVISION" and look for the "renamed"
> report in the result, which will then provide the previous name).

But when we're asking for 'annotate' for a file in some old revision 
(under old name), it won't be the same revision where it had been 
renamed, 99% of the time.

> (FTR: I used src/unexcoff.c file to test this.)
> 
>> +*** Support for viewing file change history across renames.
>> +When a fileset's VC change history ends at a rename, we now print the
>> +old name(s) and a button which jumps to their history.  Only supported
>> +with Git at the moment.
> 
> I think this should at least tell that for files under Bazaar, the VC
> change history will always include the renames.  Looks like Mercurial
> is in the same department as Git?

More or less, yes, here's an even older bug report: 
https://debbugs.gnu.org/13004

> If so, I think the text should say
> that this is not supported for Mercurial yet, and that Bazaar shows
> the entire history, including renames, by default.  Or something like
> that.

I don't want to make it a sticking point, but according to the wiki 
entry Monotone also tracks renames. We won't be mentioning it here, will we?

I don't think we're going to persuade anybody new to use Bazaar here, 
and those who currently use it, probably don't pay this issue (the lack 
of it) much attention.

> I also think this entry should mention the relevant VC commands
> ("C-x v l" and what else?), since otherwise "VC change history"
> is not concrete enough to tell users which command(s) is/are affected.

Ok.

Just 'C-x v l', with one or more files selected. The remaining 2 
vc-print-* commands print the history for all files, so all renames are 
naturally included. One cannot use 'f' or 'a' on their output, though.

Message #56 received at 55871 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 55871 <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 17:10:22 +0200

> Date: Fri, 15 Dec 2023 16:39:04 +0200
> Cc: 55871 <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> > FYI: 'd' and 'f' work with bzr without any changes.
> 
> To my understanding, Bazaar doesn't really exist in this day and age, so 
> should we pay extra attention to it in this NEWS entry?

Bazaar is still being developed, but I don't know how important it is
nowadays.  I do use it here, FWIW (and keep the old repository under
Bazaar, from before the switch, for the rare occasion I need to look
up or try something there).

> We could say that the problem is relevant to Git and Hg, and the current 
> solution only helps Git. I'm not sure what's the best phrasing, however, 
> which won't bloat the NEWS entry too much.

That'd be fine, and the wording could just use what you say above.

> > 'a' doesn't work
> > (evidently, "bzr annotate -r REVISION FILE" doesn't work when FILE did
> > not exist in REVISION, but was renamed by a later revision, and one
> > needs to run "bzr status -Sr REVISION" and look for the "renamed"
> > report in the result, which will then provide the previous name).
> 
> But when we're asking for 'annotate' for a file in some old revision 
> (under old name), it won't be the same revision where it had been 
> renamed, 99% of the time.

It doesn't matter.  The above-mentioned bzr command will show the
telltale "RM old => new" status.  Keep in mind that "-r REVISION" in
bzr means "since REVISION till the current head".

> > (FTR: I used src/unexcoff.c file to test this.)
> > 
> >> +*** Support for viewing file change history across renames.
> >> +When a fileset's VC change history ends at a rename, we now print the
> >> +old name(s) and a button which jumps to their history.  Only supported
> >> +with Git at the moment.
> > 
> > I think this should at least tell that for files under Bazaar, the VC
> > change history will always include the renames.  Looks like Mercurial
> > is in the same department as Git?
> 
> More or less, yes, here's an even older bug report: 
> https://debbugs.gnu.org/13004
> 
> > If so, I think the text should say
> > that this is not supported for Mercurial yet, and that Bazaar shows
> > the entire history, including renames, by default.  Or something like
> > that.
> 
> I don't want to make it a sticking point, but according to the wiki 
> entry Monotone also tracks renames. We won't be mentioning it here, will we?

vc-monotone is not part of Emacs, right?

It is okay to say "is not yet supported for Hg".

Message #61 received at 55871-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 55871-done <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 22:45:24 +0200

Version: 30.1

On 15/12/2023 17:10, Eli Zaretskii wrote:
>> Date: Fri, 15 Dec 2023 16:39:04 +0200
>> Cc: 55871 <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>>
>>> FYI: 'd' and 'f' work with bzr without any changes.
>>
>> To my understanding, Bazaar doesn't really exist in this day and age, so
>> should we pay extra attention to it in this NEWS entry?
> 
> Bazaar is still being developed, but I don't know how important it is
> nowadays.  I do use it here, FWIW (and keep the old repository under
> Bazaar, from before the switch, for the rare occasion I need to look
> up or try something there).

I'm hoping this change will make it easier to investigate old 
changesets, so you won't need to keep a separate repository (I do have 
several worktrees for Emacs around, but they're all managed by Git).

>> We could say that the problem is relevant to Git and Hg, and the current
>> solution only helps Git. I'm not sure what's the best phrasing, however,
>> which won't bloat the NEWS entry too much.
> 
> That'd be fine, and the wording could just use what you say above.

Ah well, while investigating what Hg does and does not, I ended up 
implementing the change for it as well.

Problem is, while it "natively tracks renames", it likewise requires a 
"--follow" flag, which is only supported in "hg log" but not "hg diff". 
So we just as well have to dig around to find what were the previous 
names. That's what the new vc-hg-file-name-changes does, except in a 
less reliable way than the Git solution (WRT odd file names).

>>> 'a' doesn't work
>>> (evidently, "bzr annotate -r REVISION FILE" doesn't work when FILE did
>>> not exist in REVISION, but was renamed by a later revision, and one
>>> needs to run "bzr status -Sr REVISION" and look for the "renamed"
>>> report in the result, which will then provide the previous name).
>>
>> But when we're asking for 'annotate' for a file in some old revision
>> (under old name), it won't be the same revision where it had been
>> renamed, 99% of the time.
> 
> It doesn't matter.  The above-mentioned bzr command will show the
> telltale "RM old => new" status.  Keep in mind that "-r REVISION" in
> bzr means "since REVISION till the current head".

Ah, you mean some code will need to search through the changes up until 
revision to find all renames anyway? I suppose that could be implemented 
in vc-bzr-annotate (independent of this changeset).

>>> (FTR: I used src/unexcoff.c file to test this.)
>>>
>>>> +*** Support for viewing file change history across renames.
>>>> +When a fileset's VC change history ends at a rename, we now print the
>>>> +old name(s) and a button which jumps to their history.  Only supported
>>>> +with Git at the moment.
>>>
>>> I think this should at least tell that for files under Bazaar, the VC
>>> change history will always include the renames.  Looks like Mercurial
>>> is in the same department as Git?
>>
>> More or less, yes, here's an even older bug report:
>> https://debbugs.gnu.org/13004
>>
>>> If so, I think the text should say
>>> that this is not supported for Mercurial yet, and that Bazaar shows
>>> the entire history, including renames, by default.  Or something like
>>> that.
>>
>> I don't want to make it a sticking point, but according to the wiki
>> entry Monotone also tracks renames. We won't be mentioning it here, will we?
> 
> vc-monotone is not part of Emacs, right?

We do have vc-mtn.el in lisp/obsolete. Anyway...

I've pushed the change to master (5b80894d0a7) to encourage wider 
testing. There are some potential follow-ups remaining (e.g. the 
question whether the "old" log should start with the exact same revision 
as the one that the "new" log ended at -- that makes a difference in 
some edge cases), but they should be small enough.

Either way, looking forward to the feedback (and if you want to do any 
edits to the NEWS entry, please go ahead).

Message #64 received at 55871-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 55871-done <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
Subject: Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f',
 'd' do not work when following renames)
Date: Sat, 16 Dec 2023 09:21:43 +0200

> Date: Fri, 15 Dec 2023 22:45:24 +0200
> Cc: 55871-done <at> debbugs.gnu.org, n.oje.bar <at> gmail.com
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> 
> >> We could say that the problem is relevant to Git and Hg, and the current
> >> solution only helps Git. I'm not sure what's the best phrasing, however,
> >> which won't bloat the NEWS entry too much.
> > 
> > That'd be fine, and the wording could just use what you say above.
> 
> Ah well, while investigating what Hg does and does not, I ended up 
> implementing the change for it as well.

Thanks.

> >>> 'a' doesn't work
> >>> (evidently, "bzr annotate -r REVISION FILE" doesn't work when FILE did
> >>> not exist in REVISION, but was renamed by a later revision, and one
> >>> needs to run "bzr status -Sr REVISION" and look for the "renamed"
> >>> report in the result, which will then provide the previous name).
> >>
> >> But when we're asking for 'annotate' for a file in some old revision
> >> (under old name), it won't be the same revision where it had been
> >> renamed, 99% of the time.
> > 
> > It doesn't matter.  The above-mentioned bzr command will show the
> > telltale "RM old => new" status.  Keep in mind that "-r REVISION" in
> > bzr means "since REVISION till the current head".
> 
> Ah, you mean some code will need to search through the changes up until 
> revision to find all renames anyway?

Yes, similar to what vc-git/hg-file-name-changes do.

> I suppose that could be implemented in vc-bzr-annotate (independent
> of this changeset).

Yes, most probably.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.