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

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

Previous Next

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