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

[Dmitry Gutov <dgutov@yandex.ru>]

On 09/04/2015 05:20 AM, Stefan Monnier wrote:

> So I don't think we can drop the FILE argument, but we can make it
> clear that it's OK to ignore it and use default-directory instead.

That, by itself, would be an easy change to make. In the docs.

> That's why I'm suggesting to pass FILE as a relative file-name.
> It is slightly delicate, tho, since the vc-root for default-directory
> may actually be different from the vc-root for (expand-file-name
> <relativename>).

My problem with that is passing a relative file-name doesn't help any 
backend, in any way: if the file-name is relative to the current 
default-directory, vc-git-* will continue behaving exactly the same, 
whether default-directory is the root, or simply the current directory.

If the file-name is relative to some other directory that the current 
(from vc-git's standpoint) default-directory, then vc-git operations 
will simply fail. Either way, the onus is on vc-working-revision and 
other generic functions to bind default-directory. And as long as 
default-directory is right, the file-names might as well stay absolute.

> I don't think we should impose a constraint that default-directory is
> vc-root.  So, backends like Git may still have to find the vc-root
> from the default-directory (tho in many cases, the underlying executable
> will do that for us).

If default-directory is outside of $git_repo, passing a path to a file 
inside it to 'git status' doesn't work. So someone still needs to bind 
default-directory to somewhere inside it.

However - this looks like the easiest solution - binding it to 
(file-name-directory file) should work well enough for backends with 
either type of revision granularity. At least as long as the backend 
program can be called in any subdirectory of the repository.