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

[GNU bug Tracking System]

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
address@hidden)


-- 
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.

Thanks,

Jonathan

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 ---