bug#21383: Static revisions in vc-working-revision

[Dmitry Gutov <dgutov@yandex.ru>]

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.