GNU bug report logs -
#26066
vc-git-status gives wrong result when called from outside repository
Previous Next
Reported by: Jonathan Ganc <jonganc <at> gmail.com>
Date: Sun, 12 Mar 2017 02:45:02 UTC
Severity: minor
Tags: patch
Found in versions 25.2, 26.0.50, 24.5
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
Full log
Message #46 received at 26066 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I have attached my proposed patch to use 'git status' for finding the
git status of files.
I have also attached git-test.sh, which generates a subdirectory
git-test with files in all the relevant git states I could think of (if
you use it, look at the mods, repo2, repo3 directories for interesting
files).
I then verified that 1) my function gives the same result as
vc-git-dir-status-files where vc-git-dir-status-files shows the file,
with one exception: if a file has a merge conflict (i.e. the status is
"UU"), my function returns conflict; 2) it is the same speed as the
current vc-git-state.
I may try eventually try rewriting vc-git-dir-status-files using this
since it appears to be about an order of magnitude faster than the
current implementation.
On 03/22/2017 10:18 PM, Jonathan Ganc wrote:
> Hi,
>
> Thanks for both responses.
>
>
>>> 3. It would be nice to be able to show mutiple directory trees at
>>> once in Neotree, though this is not as important.
>>
>> If it's unable to show the non-current projects, how is the bug
>> triggered? default-directory would have to be outside of the project.
>
> I'm not actually sure why it is causing me problems. I just tried
> using Neotree and encountered this problem. I didn't try anything
> special besides opening the window. I'm not sure how/why Neotree sets
> default-directory. I need to look into this.
>
>
>> The problem might have gone unnoticed until now because file's status
>> is cached, and because it can only be apparent if several projects
>> are opened at the same time.
>>
>> While the problem is fairly obvious, a proper fix would most likely
>> touch other backends and commands, to the point that the
>> default-directory binding might have to be done inside vc-call-backend.
>
> 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. 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).
>
> 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.
>
> At the very least, the documentation for vc-git-state should note that
> default-directory needs to be set.
>
>>
>> There is a very simple workaround on the caller's side, though: bind
>> default-directory inside the Neotree code, to the respective project
>> root (or just the file's parent directory). That will be necessary
>> anyway for it to work in the released Emacs versions.
>>
>
> That may be the best answer. I am not so familiar with the Neotree
> code but it should be doable.
>
>>> 2. I would like to be able to color directories as well as files. I
>>> don't know if that is something that would have a component in
>>> vc-git.el / vc-....el or would go entirely in some package (e.g.
>>> Neotree)
>>
>> This differs from one version control system to another, but Git
>> doesn't actually track directories. So the notion of "directory
>> status" is poorly defined. But see the previously mentioned
>> diff-hl-dired-mode.
>>
>
> 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)`.
>
> I started looking through diff-hl. It looks like it has a bunch of
> neat and useful features, though I admit I was a bit confused by the
> workflow.
>
[git-test.sh (application/x-shellscript, attachment)]
[0001-Use-git-status-in-vc-git-status.patch (text/x-patch, attachment)]
This bug report was last modified 4 years and 344 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.