VCS_STATUS_NUM_STAGED reports double of correct amount inside a certain path
gitstatus version: 1.4.3 macOS 11.0.1 (20B50) x64
I modify 3 files, VCS_STATUS_NUM_UNSTAGED reports 3, VCS_STATUS_NUM_STAGED reports 0 then I git add ., now VCS_STATUS_NUM_UNSTAGED reports 0 while VCS_STATUS_NUM_STAGED reports 6
git status also shows 3 files modified for the changes to be committed
When I just add and stage a new file next to these, they are also reported as 2 changes, but when I add a new file in the root or inside another directory, it displays as 1 correctly. I have this repository cloned inside 2 different folders, so I can easily interrupt my current task with a quick fix/review and both of them work the same for this. (It's a private repository)
Please provide instructions how to reproduce. Which command do I need to run?
I will check my other repositories later but I can only reproduce it in a private repository currently. Even if I recreate the path in a new repository, that will report the correct number.
Please do the following:
-
cdinto the repository that exhibits this issue. - Do what you need to do in order to trigger the bug in gitstatus.
- Run this command after replacing
~/gitstatuswith the real path togitstatuson your machine:() { emulate -L zsh -o err_return git status zsh -feic ' GITSTATUS_LOG_LEVEL=DEBUG source ~/gitstatus/gitstatus.plugin.zsh gitstatus_start -s -1 -u -1 -c -1 -d -1 -m -1 MY gitstatus_query MY typeset -m "VCS_STATUS_*" sleep 2 gitstatus_query MY typeset -m "VCS_STATUS_*" cat -- $GITSTATUS_DAEMON_LOG_MY' } &>/tmp/gitstatus.txt - Attach
/tmp/gitstatus.txtto this issue.
I sent you the log in email because it contains a bunch of filenames.
I sent you the log in email because it contains a bunch of filenames.
I haven't received it. My email is [email protected].
I sent it again, then I realized my VPN client is acting up again, so I restarted it.
Thanks, I've now received the same email twice.
What is the output of the following command?
locale
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL="en_US.UTF-8"
This is on a case-insensitive filesystem, right?
yes
Copied some of the old formulas from here and all the versions I tried have this bug (1.1.0, 1.1.1, 1.2.2, 1.3.0)
I haven't looked at it yet. Before debugging this I'll need to reproduce it locally and that would be much easier if I had more info about your repository.
Please verify that the list of files in the repository is all that's necessary to reproduce this problem. To do that, run the following commands when your current directory is the root of your git repository:
rm -rf -- /tmp/repo
git ls-files | LC_ALL=C sort >/tmp/git-files
mkdir /tmp/repo
cd /tmp/repo
git init
xargs mkdir -p -- </tmp/git-files
xargs rmdir -- </tmp/git-files 2>/dev/null
xargs touch -- </tmp/git-files
xargs git add -- </tmp/git-files
git commit -m 'initial commit'
When these commands finish, you'll be in /tmp/repo. This is a git repository that has the same files as your real git repository but these files are all empty. Please check whether gitstatus exhibits the same problem in this repository.
If you can confirm this, it would help a lot if you could send me /tmp/git-files.
Yep, still messed up with empty files, sent it to you in email.
Sorry that I haven't done anything here.
No worries, I started using zsh-async to update the prompt when git status parsing is ready, so the performance of git status parsing is not that critical anymore.