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

Package: emacs;

Reported by: Wojciech Siewierski <wojciech.siewierski <at> gmail.com>

Date: Mon, 3 Apr 2017 00:06:02 UTC

Severity: normal

Found in version 25.1

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

Full log


View this message in rfc822 format

From: Jakub Ječmínek <kuba <at> kubajecminek.cz>
To: Dmitry Gutov <dgutov <at> yandex.ru>, Sean Whitton <spwhitton <at> spwhitton.name>
Cc: eliz <at> gnu.org, 26345 <at> debbugs.gnu.org, wojciech.siewierski <at> gmail.com
Subject: bug#26345: [PATCH] Handle renamed files when cycling through revisions
Date: Sun, 6 Jul 2025 23:30:11 +0200
I'm sending the e-mail again, I think my previous message was malformed.

Sean Whitton <spwhitton <at> spwhitton.name> writes:

> But is the call to vc-git-registered needed at all?  Why not just look
> at the file name changes list immediately, and if the file does not
> appear there, assume that the original file name is valid?

I think you're right, looking at `vc-*-file-name-changes' should be enough.

> And maybe then this could happen up in vc-annotate instead of being
> Git-specific.  It's kind of a heuristic anyway.

The problem occurs when we call `vc-annotate-next-revision', which in
turn calls `vc-annotate-warp-revision'. I can make the change there, but
I'm not familiar with any VCS other than Git, so I can't test it.

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

> On 05/07/2025 19:42, Sean Whitton wrote:
> I think (?) the file name might have changed in some later revision - so
> it won't be returned by vc-git-file-name-changes for that specific REV,
> but still might not match the current name.

I'm not sure.




This bug report was last modified 8 days ago.

Previous Next


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