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

[Jonathan Ganc <jonganc@gmail.com>]

Hi,

I am just checking if anyone has had a chance to review my proposed 
improvement to vc-git-status? I have been using it without problem but I 
would love to get feedback.

Jonathan


On 03/30/2017 11:16 PM, Jonathan Ganc wrote:
> 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.
>>
>