GNU bug report logs - #26345
25.1; vc-annotate in Git is unable to fully navigate the history if the file was moved

Previous Next

Full log

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

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Jakub Ječmínek <kuba <at> kubajecminek.cz>,
 Sean Whitton <spwhitton <at> spwhitton.name>
Cc: 26345 <at> debbugs.gnu.org, wojciech.siewierski <at> gmail.com
Subject: Re: bug#26345: [PATCH] Handle renamed files when cycling through
 revisions
Date: Tue, 29 Jul 2025 04:32:50 +0300

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

Hi all!

On 26/07/2025 23:14, Jakub Ječmínek via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
> Sean Whitton<spwhitton <at> spwhitton.name> writes:
> 
>>>> Seems like this needs to be investigated before we can proceed.
>>> I've tested various scenarios and haven't encountered any issues with the
>>> current implementation. It would be great if you could test the change as
>>> well, in case there are edge cases I missed.
>> I think that we need to see an argument in terms of the definition of
>> the file-name-changes backend function that demonstrates that your
>> approach will always work:
>>
>> ;;   Return the list of pairs with changes in file names in REV.  When
>> ;;   a file was added, it should be a cons with nil car.  When
>> ;;   deleted, a cons with nil cdr.  When copied or renamed, a cons
>> ;;   with the source name as car and destination name as cdr.
> My approach updates the FILE argument only if the file name has changed
> in the given revision; otherwise, it keeps the name unchanged. I’m not
> sure if it will **always** work, but it does fix the issue at hand. I'm
> sorry, but I can't provide any further arguments in favor of this
> change.

Looking over the bug report again, my previous question was off the 
mark: it was about longer jumps over revisions - but the 'j' and 'a' 
commands (which are probably the only examples of such in the tree) 
specify the target file name explicitly (getting it from the buffer 
contents), so they should be okay. For the 'n' and 'p' commands, it 
would usually be fine because the step is often 1 revision.

Anyway, that patch seems to fix stepping forward once across a name 
change, but not farther, nor stepping backward over such a change.

To reproduce, add steps like this to the original setup:

  $ echo "
morecontent" > newdir/file.txt
  $ git commit -m 'Edit after the move, adding second line'

And then this to the reproduction:

  5. Press 'n' again.
  6. Press 'p' twice.

It seems the fix is to move the change from 'vc-annotate' to 
'vc-annotate-warp-revision' (previously mentioned by Jakub), and to 
update the new function to handle both directions.

Please try out the the attached update, it seems handle both.

I did some quick testing with Mercurial too.

[vc-annotate-follow-changed-names.diff (text/x-patch, attachment)]

Previous Next

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