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

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: 21383-done <at> debbugs.gnu.org, Jonathan H <pythonnut <at> gmail.com>
Subject: bug#21383: Static revisions in vc-working-revision
Date: Thu, 03 Sep 2015 12:04:35 -0400

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

I think the problem is in the contract between VC itself and the
backends, because VC mostly assumes that default-directory doesn't
matter and uses absolute file names instead (that was the original
design), whereas for many backends this is sometimes inconvenient so
they occasionally rely on default-directory instead, which happens to
work as well, tho it's mostly an accident.

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

Clearly, what I suggest would require changes in the core VC code, yes.

> And are you talking about FILE arg to vc-status, or e.g. vc-git-status?

vc-git-status (and other backend operations).

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

Right, we could fix the problem by keeping the original design and
making sure the backends actually follow it, but I'm not sure it's the
better design nowadays (and since using default-directory happens to
work in 99% of the cases, it's hard to make sure we really fix all cases
where we incorrectly rely on default-directory being the right parent of
the absolute file names we get).


        Stefan

Previous Next

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