[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: Tue, 11 Apr 2017 03:07:21 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.0

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".

reply via email to

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