emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#55871: closed (27.1; vc-git.el log view 'a', 'f', 'd' do not work wh


From: GNU bug Tracking System
Subject: bug#55871: closed (27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames)
Date: Fri, 15 Dec 2023 20:46:01 +0000

Your message dated Fri, 15 Dec 2023 22:45:24 +0200
with message-id <91c5ddd8-f351-8762-abca-a577acdb942d@yandex.ru>
and subject line Re: bug#55871: Acknowledgement (27.1; vc-git.el log view 'a', 
'f', 'd' do not work when following renames)
has caused the debbugs.gnu.org bug report #55871,
regarding 27.1; vc-git.el log view 'a', 'f', 'd' do not work when following 
renames
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
55871: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=55871
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: 27.1; vc-git.el log view 'a', 'f', 'd' do not work when following renames Date: Thu, 9 Jun 2022 11:54:44 +0200
When pressing 'C-x v l' in a git versioned file that has been renamed,
it is possible to get a full history (ie including renames) by setting
'vc-git-print-log-follow' to t.

However, if doing this, the functions

- 'd' (log-view-diff)
- 'f' (log-view-find-revision)
- 'a' (log-view-annotate-revision)

stop working with revisions "before" the rename. There is a previous
discussion of this problem in

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=8756

but the discussion ends by suggesting to open a new bug report about
this issue, which I am doing here.

In GNU Emacs 27.1 (build 1, x86_64-w64-mingw32)
 of 2020-08-21 built on CIRROCUMULUS
Repository revision: 86d8d76aa36037184db0b2897c434cdaab1a9ae8
Repository branch: HEAD
Windowing system distributor 'Microsoft Corp.', version 10.0.22000
System Description: Microsoft Windows 10 Pro (v10.0.2009.22000.708)

Recent messages:
process
Mark saved where search started
Saving file c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf...
Mark set
Wrote c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf
Wrote c:/cygwin64/home/nojebar/mlfi/applications/scheduler/main.mf (3
pending errors, use C-c C-x to jump)
Mark saved where search started [3 times]
Mark set
Mark saved where search started [13 times]
Quit [2 times]
Quit
Configured using:
 'configure --without-dbus --host=x86_64-w64-mingw32
 --without-compress-install 'CFLAGS=-O2 -static''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: fr_FR.UTF-8
  locale-coding-system: cp1252

Major mode: caml

Minor modes in effect:
  shell-dirtrack-mode: t
  merlin-mode: t
  save-place-mode: t
  winner-mode: t
  savehist-mode: t
  show-paren-mode: t
  delete-selection-mode: t
  display-time-mode: t
  global-auto-revert-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  size-indication-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
c:/cygwin64/home/nojebar/mlfi/mlfi-ins/share/emacs/site-lisp/ocp-indent
hides ~/scripts/install/emacs/ocp-indent
c:/cygwin64/home/nojebar/.emacs.d/elpa/jsonrpc-1.0.15/jsonrpc hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/jsonrpc
c:/cygwin64/home/nojebar/.emacs.d/elpa/xref-1.4.1/xref hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/xref
c:/cygwin64/home/nojebar/.emacs.d/elpa/project-0.8.1/project hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/project
c:/cygwin64/home/nojebar/.emacs.d/elpa/flymake-1.2.2/flymake hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/progmodes/flymake
c:/cygwin64/home/nojebar/.emacs.d/elpa/seq-2.23/seq hides c:/Program
Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/seq
c:/cygwin64/home/nojebar/.emacs.d/elpa/eldoc-1.12.0/eldoc hides
c:/Program Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/eldoc
~/scripts/install/emacs/cl-lib hides c:/Program
Files/emacs-27.1/share/emacs/27.1/lisp/emacs-lisp/cl-lib

Features:
(shadow sort mail-extr emacsbug message rmc puny format-spec rfc822 mml
mml-sec epa epg epg-config gnus-util rmail rmail-loaddefs
text-property-search time-date mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils add-log log-view pcvs-util
help-fns radix-tree vc-annotate ffap grep thingatpt cl-extra help-mode
shell pcomplete smerge-mode diff vc vc-dispatcher misearch multi-isearch
merlin-xref xref project merlin-cap merlin pcase caml-types crm caml
advice rx compile derived imenu cygwin-mount ange-ftp comint ansi-color
ocamlformat ocp-indent caml-font vc-git diff-mode easy-mmode dired-x
dired dired-loaddefs saveplace edmacro kmacro winner ring savehist paren
delsel time autorevert filenotify info proof-site proof-autoloads
package easymenu browse-url url-handlers url-parse auth-source cl-seq
eieio eieio-core cl-macs eieio-loaddefs password-cache json subr-x map
url-vars seq byte-opt gv bytecomp byte-compile cconv cl-loaddefs cl-lib
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 298590 19356)
 (symbols 48 12729 1)
 (strings 32 40782 1936)
 (string-bytes 1 1406019)
 (vectors 16 22528)
 (vector-slots 8 276819 12620)
 (floats 8 104 554)
 (intervals 56 42748 0)
 (buffers 1000 42))



--- End Message ---
--- Begin Message --- 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 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/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).


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]