[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.
- bug#26066: 26.0.50; vc-git-status gives wrong result, (continued)
- bug#26066: 26.0.50; vc-git-status gives wrong result, Dmitry Gutov, 2017/04/09
- bug#26066: 26.0.50; vc-git-status gives wrong result, Dmitry Gutov, 2017/04/10
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/10
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/11
- bug#26066: 26.0.50; vc-git-status gives wrong result,
Dmitry Gutov <=
- bug#26066: 26.0.50; vc-git-status gives wrong result, Dmitry Gutov, 2017/04/11
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/13
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/23
- bug#26066: 26.0.50; vc-git-status gives wrong result, Noam Postavsky, 2017/04/23
- bug#26066: 26.0.50; vc-git-status gives wrong result, Stefan Monnier, 2017/04/23
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/23
- bug#26066: 26.0.50; vc-git-status gives wrong result, Andreas Schwab, 2017/04/24
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/25
- bug#26066: 26.0.50; vc-git-status gives wrong result, Dmitry Gutov, 2017/04/25
- bug#26066: 26.0.50; vc-git-status gives wrong result, Jonathan Ganc, 2017/04/25