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

Previous Next

Full log

View this message in rfc822 format

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: bug#21383: Static revisions in vc-working-revision
Date: Wed, 2 Sep 2015 13:49:10 +0300

On 09/02/2015 06:50 AM, Stefan Monnier wrote:
>> Maybe you see it better.  I only imagined the problem limited to the
>> non-file-granularity backends.
>
> You mean like most current backends? ;-)

Yes. But as long as its only limited to the backends (and can be fixed 
there), as opposed to being inherently present in vc.el, log-edit.el, 
etc, it's less of a problem.

>> And we can't simply remove the FILE argument in many backend commands: it's
>> often used for vc-file-get/setprop.
>
> I know.
>
> In any case, it's not that bad: it works.  But there's something fishy
> that will surely bite at some point.  Maybe those FILE args should be
> redefined to be relative to default-directory (and can't use things like
> "../..").

vc-file-setprop won't work on a relative path. Or shouldn't, at least.

And are you talking about FILE arg to vc-status, or e.g. vc-git-status? 
If vc-status requires the path to be relative, that will complicate the 
consumer interface (now I have to worry about producing the relative 
path). If vc-status will be responsible for that before calling 
vc-git-status, it won't work in file-granular backends. Anyway, why 
would we want that extra call, even if it's cached?

And vc-git-working-revision won't care if FILE is absolute or relative, 
which is the crux of the problem. I'd rather backends like Git, if we're 
going to fix this, used FILE's parent directory to change 
default-directory temporarily before calling Git.

Previous Next

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