[Top][All Lists]

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

[debbugs-tracker] bug#21383: closed (Static revisions in vc-working-revi

From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#21383: closed (Static revisions in vc-working-revision)
Date: Tue, 01 Sep 2015 12:06:01 +0000

Your message dated Tue, 1 Sep 2015 15:05:27 +0300
with message-id <address@hidden>
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

21383: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21383
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: Static revisions in vc-working-revision Date: Sun, 30 Aug 2015 17:45:25 -0700
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 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.


Attachment: 0001-Add-CONCRETE-parameter-to-vc-working-revision.patch
Description: Binary data

--- End Message ---
--- Begin Message --- Subject: Re: bug#21383: Static revisions in vc-working-revision Date: Tue, 1 Sep 2015 15:05:27 +0300 User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0
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.

--- End Message ---

reply via email to

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