bug-gnu-emacs
[Top][All Lists]
Advanced

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

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


From: Dmitry Gutov
Subject: bug#21383: Static revisions in vc-working-revision
Date: Wed, 2 Sep 2015 13:49:10 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0

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.





reply via email to

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