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

From: Dmitry Gutov <[email-masked]>
Date: Tue, 11 Apr 2017 03:07:21 +0300

On 23.03.2017 04:18, Jonathan Ganc wrote:

> Yeah, I'm not really sure what the workflow should be; I'm just getting 
> started with the vc functions in emacs. One issue, though, is that 
> default-directory can only be set for functions that identify a 
> filename, because we need to have a directory to set things to. For this 
> reason, I don't know that one could generally set default-directory in 
> vc-call-backend.

You are right. But we could set it in vc-state-refresh.

> It could make sense to set default-directory for 
> vc-git--run-command-string (although to get vc-git-state to work, one 
> would still need to set it for vc-git--empty-db-p).

That's also an option, yes. But binding it on the higher level would be 
better, I think.

> It's worth nothing there seems to be inconsistency within vc-git. Some 
> commands like vc-git-checkin, vc-git-next-revision, do set 
> default-directory to the directory of the input file; other comands like 
> vc-git-merge-branch seem to do the opposite and assume the root is 
> already given by default-directory.

True. Some of those occurrences are most likely there just so the DIR 
argument is not left unused. Some have less obvious reasons.

vc-git-checkin, for instance, does it to call 'git commit' from the 
repository root, instead of an arbitrary directory in it. I'm sure it's 
really necessary, though.

> At the very least, the documentation for vc-git-state should note that 
> default-directory needs to be set.

The backend-specific functions are largely internal, we don't expect 
clients to call them directly. If anything, the documentation can be 
clarified on whether an arbitrary backend's 'state' command should set 
default-directory, or use the current one.

> You're right, in principle, but atom handles it by coloring directories 
> based on if they have modified files within. I don't know if there is a 
> "canonical" way to do this, although one idea would be to return a list 
> of all file status in the directory, e.g. `(up-to-date modified ignored)`.

Yeah, diff-hl-dired does something like that. If all the "interesting" 
statuses in a directory are the same, we assign it that status. If 
they're mixed, we mark it as "changed".