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

Previous Next

Full log

View this message in rfc822 format

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

Previous Next

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