|
| From: | Dmitry Gutov |
| 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 |
| User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
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/13004If 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).
| [Prev in Thread] | Current Thread | [Next in Thread] |