bug#26066: 26.0.50; vc-git-status gives wrong result

[Dmitry Gutov]

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.