bug: explorer doesn't always update its git status icon if the state changes outside of the explorer

[nickjj]

Did you check docs and existing issues?

• [x] I have read all the snacks.nvim docs
• [x] I have updated the plugin to the latest version before submitting this issue
• [x] I have searched the existing issues of snacks.nvim
• [x] I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.10.4

Operating system/version

Ubuntu 22.04

Describe the bug

If you modify files in a git repo, the explorer puts nice icon indicators to let you know the state of the file. If you commit changes with the git cli directly or use a tool like gitui to commit files then the explorer will show an icon that a file was changed and this only goes away after closing + opening the explorer or individually saving the associated file in Neovim even if the contents didn't change.

Here's a screenshot where I used the git CLI to commit changes to a few files:

This occurs even when using gitui that was invoked directly inside of Neovim such as when using LazyVim which optionally sets things up to use it within Neovim in a floating window.

With that said, in a way it's almost a feature to know that the state of a file changed externally and now you need to take an action to clear it so feel free to close this if that behavior is intended.

Steps To Reproduce

1. Create a git repo
2. Add files and commit files
3. Open Neovim
4. Toggle the explorer open
5. Modify one of the files and save it
6. Use the git CLI to create the commit
7. Notice the icon in the explorer window next to the file
8. Save the file in Neovim even with no changes
9. Notice the icon in the explorer window goes away

Expected Behavior

Steps 7 and 8 in the above workflow wouldn't be needed to get the explorer to reflect the state of the file.

[dpetka2001]

I tried to repro but this doesn't happen to me. Screencast following

https://github.com/user-attachments/assets/0922d08e-d456-40b0-9852-ae35f17f4b5f

I don't use gitui, so I just tried with git cli that you mentioned as well.

[nickjj]

GitHub says your video is corrupt, it cannot be played back.

Are there any settings or things I can do to enable more visibility on what might be different within our set up? I am using WSL 2 but the files live inside of WSL 2's file system where Neovim is installed so there shouldn't be any Windows related mounts affecting inotify events. Other file updates appear immediately so the events are getting there (including this one).

I am using LazyVim with the most recent updates for all installed plugins.

git --version is also git version 2.34.1 if it helps.

[dpetka2001]

GitHub says your video is corrupt, it cannot be played back.

I have no problem watching it in Firefox web browser. Maybe it's a browser's codecs difference? I can try to upload somewhere else if you have another service to suggest.

The only difference I can see from your description is that I'm on Linux Mint 21.3 (so no WSL) and my git version is 2.49.0. I tested with default LazyVim installation, so that my personal configuration wouldn't affect anything.

Here's a link from the video uploaded in streamable host. I can watch it there in Firefox browser as well on my end.

PS: If you think there's another step I should take in my testing, please feel free to make a suggestion. I believe I followed the steps 1-7 without needing steps 8-9.

PS2: Here's also a link from my google drive. I can save it locally and watch it with VLC without problem.

[nickjj]

I have no problem watching it in Firefox web browser

Weird, Firefox is failing to load it on Windows but Chrome works.

If I repeat your steps I end up with the aqua icon which indicates something new has been staged. It doesn't go away like yours does at 1:05 from the action you took at 0:57 to commit it. At 1:00, that is the state of my explorer at the very end.

[dpetka2001]

Yes, I understand that must have been the case from your description. I just tried to see if I could repro, but couldn't like I showed in the video. Could you try updating your git to 2.49.0? If that also doesn't make any difference, then it must be some kind of difference of how git operates in WSL vs native Linux. But I have no idea about that.

To install latest version I used from here the ppa add-apt-repository ppa:git-core/ppa

[nickjj]

Upgrading to the latest git still has the issue. Funny enough if I undo a commit, the status gets updated correctly. It's only that icon for staging changes that gets stuck based on what I've seen so far.

All of this is through the normal git client, gitui isn't being used.

Are you using the default Kernel that came with Linux Mint 21.3? I doubt it's a Kernel bug but if you are using the default, that at least demonstrates things work with older Kernel versions than what's in 22.04.

[nickjj]

I am able to reproduce this on macOS on a work laptop. That git staged icon does not get updated in the same way after committing with the git CLI.

In both cases I am using the same Neovim / LazyVim / dotfiles configuration at https://github.com/nickjj/dotfiles/tree/master/.config/nvim. The same version of Neovim too except it's arm64 (M2) vs amd64 on my personal Windows / WSL 2 machine.

[dpetka2001]

Yes, default kernel that comes with Linux Mint 21.3 and only upgrade via apt upgrade whenever there are updates. I believe I followed correctly the steps that you outlined, right? No idea what other differences between the git operations on different OSes.

Hopefully maintainer will have a better idea.

[nickjj]

Thanks. I will record a video later today or tomorrow morning to help identify.

[nickjj]

Here's the video reproducing it on my WSL 2 personal machine. The same thing happens on macOS:

https://github.com/user-attachments/assets/07a06545-3142-416f-ad90-603b069a333c

Don't judge me for using the mouse haha. I was purposely using it to demonstrate where I was clicking.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[nickjj]

Replying so it doesn't expire.

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue was closed because it has been stalled for 7 days with no activity.

[gengdz]

Replying so it doesn't expire.