GNU bug report logs - #15696
24.3; vc-git-annotate-command -- ambiguous short commit hashes cause failures

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 15696 in the body.
You can then email your comments to 15696 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "Phil Sainty" <psainty <at> orcon.net.nz>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; vc-git-annotate-command -- ambiguous short commit hashes cause 
 failures
Date: Thu, 24 Oct 2013 11:36:31 +1300 (NZDT)

`vc-git-annotate-command' looks like this:

(defun vc-git-annotate-command (file buf &optional rev)
  (let ((name (file-relative-name file)))
    (vc-git-command buf 'async nil "blame" "--date=iso" "-C" "-C" rev "--"
name)))

By default, git blame produces short commit hashes. You need to pass
the -l argument to make it produce full hashes.

This is a problem if the short hash is ambiguous, as none of the
vc-annotate commands for interacting with that commit work.

Example errors for ambiguous commit hash 7b10edf8:

'f' (`vc-annotate-find-revision-at-line'):
Checking out (filename).~7b10edf8~...
vc-do-command: Running git cat-file blob 7b... ....FAILED (status 128)

'D' (`vc-annotate-show-changeset-diff-revision-at-line'):
Cannot diff from any revision prior to 7b10edf8

'l' (`vc-annotate-show-log-revision-at-line'):
error: short SHA1 7b10edf8 is ambiguous.
fatal: bad revision '7b10edf8'

'a' (`vc-annotate-revision-previous-to-line'):
vc-annotate-warp-revision: Invalid argument to vc-annotate-warp-revision

On the command line:
$ git show 7b10edf8
error: short SHA1 7b10edf8 is ambiguous.
error: short SHA1 7b10edf8 is ambiguous.
fatal: ambiguous argument '7b10edf8': unknown revision or path not in the
working tree.
Use '--' to separate paths from revisions


I suspect the best solution is to pass -l by default, and perhaps
*hide* the remainder of the full commit hash in the annotate buffer
-- but internally always utilise the full hash for all commands.

(Will this also be a problem elsewhere in the vc-git support?)


-Phil




In GNU Emacs 24.3.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.2)
 of 2013-03-12 on shodan
Windowing system distributor `The X.Org Foundation', version 11.0.11103000
System Description:	Ubuntu 12.04.3 LTS

Configured using:
 `configure '--prefix=/home/phil/emacs/emacs24/emacs-24.3/usr/local''

Important settings:
  value of $LANG: en_NZ.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-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
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<help-echo> M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Message #8 received at 15696 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "Phil Sainty" <psainty <at> orcon.net.nz>
Cc: 15696 <at> debbugs.gnu.org
Subject: Re: bug#15696: 24.3; vc-git-annotate-command -- ambiguous short
 commit hashes cause  failures
Date: Sun, 06 Dec 2020 16:17:52 +0100

"Phil Sainty" <psainty <at> orcon.net.nz> writes:

> `vc-git-annotate-command' looks like this:
>
> (defun vc-git-annotate-command (file buf &optional rev)
>   (let ((name (file-relative-name file)))
>     (vc-git-command buf 'async nil "blame" "--date=iso" "-C" "-C" rev "--"
> name)))
>
> By default, git blame produces short commit hashes. You need to pass
> the -l argument to make it produce full hashes.
>
> This is a problem if the short hash is ambiguous, as none of the
> vc-annotate commands for interacting with that commit work.
>
> Example errors for ambiguous commit hash 7b10edf8:

(This bug report unfortunately got no response at the time.)

The command in question now produces an 11-char short hash, which I
think is pretty rarely ambiguous, in my experience, so I don't think
there's anything more to fix here, and I'm closing this bug report.

If there's still a problem here, please respond to the debbugs address
and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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