GNU bug report logs - #21383
Static revisions in vc-working-revision

Previous Next

Package: emacs;

Reported by: Jonathan H <pythonnut <at> gmail.com>

Date: Mon, 31 Aug 2015 00:47:01 UTC

Severity: wishlist

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: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#21383: closed (Static revisions in vc-working-revision)
Date: Tue, 01 Sep 2015 12:06:01 +0000
[Message part 1 (text/plain, inline)]
Your message dated Tue, 1 Sep 2015 15:05:27 +0300
with message-id <55E59487.1050804 <at> yandex.ru>
and subject line Re: bug#21383: Static revisions in vc-working-revision
has caused the debbugs.gnu.org bug report #21383,
regarding Static revisions in vc-working-revision
to be marked as done.

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


-- 
21383: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21383
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems
[Message part 2 (message/rfc822, inline)]
From: Jonathan H <pythonnut <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Static revisions in vc-working-revision
Date: Sun, 30 Aug 2015 17:45:25 -0700
[Message part 3 (text/plain, inline)]
Hello all!

I've attached a basic patch that adds an option to vc-working-revision. The
option is named *concrete* and if non-nil, it forces vc-working-revision to
return a revision name that will not go stale after new revisions are made.

This is useful for, e.g. git, where vc-working-revision will just return
the branch name, which only refers to the current commit for as long as
it's the head of the branch.

I'm using this in diff-hl #33 <https://github.com/dgutov/diff-hl/issues/33>to
determine when to refresh the current VC highlighting.

I've supplied an implementation for Git, and no-op implementations for all
the other backends. For most systems (i.e. all the other VCS systems I
know), the value of *concrete *does not matter. If you know a backend that
would benefit from a real implementation, please let me know.

Also, this is my first patch, so I'm not entirely sure I've got all my
ducks in a row. Any comments on that would be great too.

Thanks,
Jonathan
[Message part 4 (text/html, inline)]
[0001-Add-CONCRETE-parameter-to-vc-working-revision.patch (application/octet-stream, attachment)]
[Message part 6 (message/rfc822, inline)]
From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 21383-done <at> debbugs.gnu.org, Jonathan H <pythonnut <at> gmail.com>
Subject: Re: bug#21383: Static revisions in vc-working-revision
Date: Tue, 1 Sep 2015 15:05:27 +0300
On 09/01/2015 06:55 AM, Stefan Monnier wrote:

> VC was originally designed so as to separate the VC data from the
> buffers, so the `file' argument was absolutely indispensable (you
> can't/shouldn't rely on things like the current-buffer's default-directory).
>
> I think nowadays the design has been changed enough that indeed the
> `file' arg can be dispensed with.

I think just the current usage, everywhere, makes it okay. But if I were 
to inquire of the status of a file in a different repository, that would 
still fail. We don't don't seem to do that anywhere, though, and 
supporting that usage would require fixes in multiple places.

This patch doesn't change much in this regard: FILE wasn't used for its 
default-directory even before it.

> The rest looks OK to me,

Thanks, installed.


This bug report was last modified 9 years and 263 days ago.

Previous Next


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