GNU bug report logs -
#21383
Static revisions in vc-working-revision
Previous Next
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
[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)]
[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)]
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.