From: Dmitry Gutov <dgutov@yandex.ru>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 55871-done@debbugs.gnu.org, n.oje.bar@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 22:45:24 +0200 [thread overview]
Message-ID: <91c5ddd8-f351-8762-abca-a577acdb942d@yandex.ru> (raw)
In-Reply-To: <83o7ero61t.fsf@gnu.org>
Version: 30.1
On 15/12/2023 17:10, Eli Zaretskii wrote:
>> Date: Fri, 15 Dec 2023 16:39:04 +0200
>> Cc: 55871@debbugs.gnu.org, n.oje.bar@gmail.com
>> From: Dmitry Gutov <dgutov@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).
next prev parent reply other threads:[~2023-12-15 20:45 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-09 9:54 bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames Nicolás Ojeda Bär
[not found] ` <handler.55871.B.16547851264967.ack@debbugs.gnu.org>
2022-06-10 17:31 ` bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames) Nicolás Ojeda Bär
2022-08-18 2:10 ` Dmitry Gutov
2022-09-06 10:56 ` bug#55871: 27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames Lars Ingebrigtsen
2022-09-06 12:12 ` Nicolás Ojeda Bär
2022-09-06 12:13 ` Lars Ingebrigtsen
2022-12-03 2:02 ` Dmitry Gutov
2022-12-11 23:02 ` bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames) Dmitry Gutov
2022-12-12 16:44 ` Nicolás Ojeda Bär
2022-12-13 1:23 ` Dmitry Gutov
2023-12-14 0:52 ` Dmitry Gutov
2023-12-14 1:23 ` Dmitry Gutov
2023-12-15 2:01 ` Dmitry Gutov
2023-12-15 13:05 ` Eli Zaretskii
2023-12-15 14:39 ` Dmitry Gutov
2023-12-15 15:10 ` Eli Zaretskii
2023-12-15 20:45 ` Dmitry Gutov [this message]
2023-12-16 7:21 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=91c5ddd8-f351-8762-abca-a577acdb942d@yandex.ru \
--to=dgutov@yandex.ru \
--cc=55871-done@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=n.oje.bar@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).