[Top][All Lists]

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

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

From: Dmitry Gutov
Subject: bug#26066: 26.0.50; vc-git-status gives wrong result
Date: Wed, 12 Apr 2017 02:27:41 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

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.

reply via email to

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