GNU bug report logs - #26066
vc-git-status gives wrong result when called from outside repository

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Jonathan Ganc <jonganc <at> gmail.com>, npostavs <at> users.sourceforge.net, 26066 <at> debbugs.gnu.org, Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: bug#26066: 26.0.50; vc-git-status gives wrong result
Date: Wed, 12 Apr 2017 02:27:41 +0300

On 11.04.2017 16:08, Jonathan Ganc wrote:
> I think I've changed my mind about where/whether to bind 
> default-directory. Since it is not universally bound by all vcs engines, 

That doesn't necessarily imply that they shouldn't.

> On the other hand, since it sometimes is 
> necessary for correct output, I do think it should be bound in 
> vc-git-state.

Is it necessary for correct output in other backends, in similar scenarios?

I agree that fixing this makes sense, but it should be done in an 
organized fashion, and separately from this patch.

If vc-git supports calling vc-git-state from outside of the repository, 
but not some other commands, or if vc-git-state does but some other 
backends' vc-xx-state does not, this will increase inconsistency and 
make it harder for the programmers to write VCS-agnostic code, which is 
one of the main goals of VC.

vc-state is also among the first functions a piece of third-party code 
would call. So it becomes the choke point which forces the caller to get 
the value of default-directory right, before any other backend commands 
are called. Until we take inventory of them, it's better to keep the bug 
in vc-state, I think.

>> Since, in principle, the vc functions should be agnostic to the choice 
>> of vcs, either a) vc-state documentation should state that 
>> default-directory should be set to get generally correct responses or

If we decide that, that should be the rule we declare for all VC backend 
commands, not just vc-state.

>> b) it should be set in some function (and I agree that 
>> vc-state-refresh makes sense).
>>
>> I think the overhead of setting the directory is rather low. In some 
>> admittedly rudimentary benchmarks, there is almost no difference in 
>> performance setting default-directory.

Yeah, I'm not worried about performance here either.

>> There's also the question of how to handle default-directory. You 
>> cannot simply do (file-name-directory file), because that fails if 
>> FILE is given without a directory. I think the correct one is 
>> (file-name-directory (expand-file-name file))

Yup, that should work. I'm not sure any of these commands are ever 
called with relative names, though.

> (which, surprisingly, is 
>> slighly faster than (file-name-directory (concat default-directory 
>> file)) ).

That probably depends on the file. The first option was faster in the 
example I've tried.

Previous Next

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