GNU bug report logs - #14459
git vc-annotate fails in detached HEAD state

Previous Next

Package: emacs;

Reported by: claudio.bley <at> gmail.com (Claudio Bley)

Date: Fri, 24 May 2013 13:38:01 UTC

Severity: normal

Fixed in version 24.4

Done: Dmitry Gutov <dgutov <at> yandex.ru>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Claudio Bley <claudio.bley <at> googlemail.com>
To: 14459 <at> debbugs.gnu.org
Subject: bug#14459: git vc-annotate fails in detached HEAD state
Date: Mon, 27 May 2013 08:41:38 +0200
At Fri, 24 May 2013 23:07:49 +0400,
Dmitry Gutov wrote:
> 
> claudio.bley <at> gmail.com (Claudio Bley) writes:
> 
> > Apparently, vc-git-working-revision calls "git symbolic-ref HEAD",
> > which - in this case - gives:
> >
> > $ git symbolic-ref HEAD
> > fatal: ref HEAD is not a symbolic ref
> >
> > So, vc-git-working-revision returns an empty string as the current
> > "revision" vc-mode refers to.
> >
> > M-: (vc-git-working-revision (buffer-file-name))
> >
> > -> ""
> >
> > When calling vc-annotate, the vc-git-annotate-command gets called with
> > the empty string for the rev parameter leading to the error.
> >
> > This patch fixes it for me: ...
> 
> I think we should fix `vc-git-working-revision' instead. After all,
> `vc-working-revision' says it returns nil when the file is not
> registered at all.
> 
> Please try this patch:
> 
> === modified file 'lisp/vc/vc-git.el'
> --- lisp/vc/vc-git.el	2013-04-24 07:52:00 +0000
> +++ lisp/vc/vc-git.el	2013-05-24 19:07:09 +0000
> @@ -237,9 +237,8 @@
>  (defun vc-git-working-revision (_file)
>    "Git-specific version of `vc-working-revision'."
>    (let* (process-file-side-effects
> -	 (str (with-output-to-string
> -		(with-current-buffer standard-output
> -		  (vc-git--out-ok "symbolic-ref" "HEAD")))))
> +         (str (or (vc-git--run-command-string nil "symbolic-ref" "HEAD")
> +                  (vc-git--run-command-string nil "rev-parse" "HEAD"))))
>      (if (string-match "^\\(refs/heads/\\)?\\(.+\\)$" str)
>          (match-string 2 str)
>        str)))

Yes, this is way better than what I've come up with. But shouldn't we
also use the "--short[=n]" option to restrict the length of the
revision string as it is displayed in the modeline? I think 40 chars
is a bit long a text taking up precious space in my modeline.

- Claudio
-- 
Claudio




This bug report was last modified 12 years and 50 days ago.

Previous Next


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