Fails to display git icons, `Shift+R` removes `git` icons

[hinell]

https://user-images.githubusercontent.com/8136158/216818824-cb9f2a13-2167-4103-8f30-8bf849f5bbab.mov

CTRL+S is bound to :update command

Description

Git icons aren't displayed. If I save an edited file (or remove existing one by dkey) , they appear again (i.e. U symbols) . But when Shift + R is hit (in the NvimTree buffer), all icons disappear.

Neovim version

NVIM v0.9.0-dev-d3355ad
Build type: MinSizeRel
LuaJIT 2.1.0-beta3

Operating system and version

Ubuntu 22.04.1 LTS

nvim-tree version

16a0e3c

Minimal config

```lua vim.g.loaded_netrw = 1 vim.g.loaded_netrwPlugin = 1 require("nvim-tree").setup({ sort_by = "case_sensitive", sync_root_with_cwd = true, open_on_tab = false, -- TODO: Open issue to make it new tab open_on_setup = true, open_on_setup_file = false, ignore_ft_on_setup={ "help", "man" }, actions = { use_system_clipboard = true }, view = { adaptive_size = true, side = "right", width = 48 }, renderer = { group_empty = true, icons = { webdev_colors = false, git_placement = "after", modified_placement = "after", glyphs = { git = { -- Git style symbols unstaged = "U", staged = "A", unmerged = "M", renamed = "R", untracked = "?", deleted = "R", ignored = "!" } } } }, filters = { dotfiles = false, }, -- Disable all keys to be set up by Legendary remove_keymaps = keystodisable }) ```

Steps to reproduce

Not even sure?

Expected behavior

All Git icons sync-ed to the working directory.

Actual behavior

No Git icons

Log

`~/.cache/nvim/nvim-tree.log` ```lua [2023-02-03 02:20:37] [git] { "git", "-C", "/home/USER/.config/nvim", "rev-parse", "--show-toplevel" } /home/USER [2023-02-03 02:20:37] [git] { "git", "-C", "/home/USER", "config", "status.showUntrackedFiles" } [2023-02-03 02:20:37] [git] running job with timeout 400ms [2023-02-03 02:20:37] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u [2023-02-03 02:20:37] [git] job timed out /home/USER nil [2023-02-03 02:22:41] [git] { "git", "-C", "/home/USER/.config/nvim/USER", "rev-parse", "--show-toplevel" } /home/USER [2023-02-03 02:22:49] [git] running job with timeout 400ms [2023-02-03 02:22:49] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u /home/USER/.config/nvim/USER M .config/nvim/USER/keymaps.lua M .config/nvim/USER/platform.lua M .config/nvim/USER/plugins-legendary.lua M .config/nvim/USER/plugins-nvim-tree.lua M .config/nvim/USER/plugins-snippets.lua M .config/nvim/USER/plugins-ui.lua M .config/nvim/USER/plugins.lua [2023-02-03 02:22:50] [git] done [2023-02-03 02:22:50] [git] job success /home/USER /home/USER/.config/nvim/USER ... repeated several times ```

[hinell]

I've checked the processes and it turns out that git subprocess simply hangs... It's listed as zombie. The repo isn't huge though.

[tjex]

there's a few things that could help make this clearer. screenshots would be ace, to see the process of what's happening (git files reappearing).

Also, as you're using the development version of neovim, there could be some quirks. Lastly, the minimal config file you've included isn't based on the supplied minimal config file.

Did you follow the steps exactly for running neovim from a barebone minimal config with neovim by using this config and running neovim with nvim -nu /tmp/nvt-min.lua?

apart from that, and considering that it is actually a bug, it could make some sense to think about how git consideres deleted files within a repo. That being that a deleted file becomes an unstaged file, as its deletion is a state change that git wants to track. So maybe it's reapearing and being given your symbol for unstaged U, becuase it is indeed an unstaged file and therefore a file to show in the tree.

But the first points of screenshots and confirming that this is happening with a minimal config would be something to check off first.

[tjex]

also as a side note the open_on_setup and related methods have been depreciated in favour of this approach which achieves the same. So it's advisable to switch to this, to save any future wonky behaviour.

[alex-courtis]

Thanks for the diagnostics @tjex

I await the results with interest...

[alex-courtis]

Not a solution, however I am investigating / warning about (timed out) zombies: #1970

[hinell]

@alex-courtis @tjex I've uploaded demo-video, checkout.

[alex-courtis]

I've uploaded demo-video, checkout.

Unfortunately that video "file is corrupt" and cannot play. You might want to try https://asciinema.org/

[alex-courtis]

@hinell I'd be most grateful if you could test this branch. It ceases git integration after 10 timeouts and better handles timed out git processes.

cd /path/to/nvim-tree.lua
git pull
git checkout 1970-handle-git-timeouts-and-zombies

Logging git operations would also be most useful.

[hinell]

@alex-courtis Checkout video againt. I've reuploaded it. The previous one was working well on chrome.

[hinell]

_Did you follow the steps exactly for running neovim from a barebone minimal config with neovim by using this config and running neovim with nvim -nu /tmp/nvt-min.lua?_

@tjex Here you go.

nvim --clean -nu /tmp/tmp.Wx9tf0h96a/nvt-min.lua

https://user-images.githubusercontent.com/8136158/216821215-042779ee-fb9f-437c-a209-085640522b72.mov

Note: I've DISABLED open_on_setup and DONT use it in all demos above.

[hinell]

I'd be most grateful if you could test this branch.

@alex-courtis Thanks! That branch made NO difference to me, except:

• :update doesn't affect NvimTree anymore
• :w (upon editable file) - reproduces this issue as usual

Why doesn't NvimTree checks git state when it's NvimTreeFocused or toggled btw?

[alex-courtis]

Why doesn't NvimTree checks git state when it's NvimTreeFocused or toggled btw?

With the default configuration git state is updated upon:

• tree open
• explicit tree refresh
• file system changes

[alex-courtis]

@alex-courtis Thanks! That branch made NO difference to me, except:

* `:update` doesn't affect NvimTree anymore

* `:w` (upon editable file) - reproduces this issue as usual

Both of those should result in git status in the tree being refreshed. I didn't see the git timeout message, however you may not have reached the threshold of 10 timeouts.

I would be most grateful for your collecting logs and repeating the minimal configuration test against the branch. Please also check for zombie git processes before exiting vim.

[hinell]

@alex-courtis I think I've narrowed down the source of the problem. The git info fails to update when cwd (:pwd) is different from the root where .git folder is found. In large repos if I open a subfolder in nvim it behaves just like the issue described.

I would be most grateful for your collecting logs

Ok. I will let you know about that later.

[alex-courtis]

The git info fails to update when when cwd (:pwd) is different from the root where .git folder is found. In large repos if I open a subfolder in nvim it behaves just like the issue described.

That's really interesting and sounds like it explains the different behaviour.

The logs should reveal exactly what is going on here.

[alex-courtis]

@hinell ^

[hinell]

@alex-courtis Sorry, have been busy with dumb neighbours. Hope I'm going to return back to this issue soon. Please don't close! Thank you!

[hinell]

I've tested the 1970-handle-git-timeouts-and-zombies branch.

Enabling plugins produced the following log. There was at least one git zombie process.

# ~/.cache/nvim/nvim-tree.log
[2023-03-25 18:09:47] [git] { "git", "-C", "/home/USER/.config/nvim", "rev-parse", "--show-toplevel" }
/home/USER
[2023-03-25 18:09:47] [git] { "git", "-C", "/home/USER", "config", "status.showUntrackedFiles" }
[2023-03-25 18:09:47] [git] running job with timeout 300ms
[2023-03-25 18:09:47] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
[2023-03-25 18:09:48] [git] timed out, killing
[2023-03-25 18:09:48] [git] job timed out  /home/USER nil
[2023-03-25 18:09:48] [git] rc=0, signal=9
# --- HIT SHIFT+R
[2023-03-25 18:10:00] [git] { "git", "-C", "/home/USER/.config/nvim/hinell", "rev-parse", "--show-toplevel" }
/home/USER
[2023-03-25 18:10:00] [git] running job with timeout 300ms
[2023-03-25 18:10:00] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
[2023-03-25 18:10:01] [git] timed out, killing
[2023-03-25 18:10:01] [git] job timed out  /home/USER nil
[2023-03-25 18:10:01] [git] rc=0, signal=9
# --- HIT SHIFT+R
[2023-03-25 18:10:16] [git] running job with timeout 300ms
[2023-03-25 18:10:16] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
[2023-03-25 18:10:16] [git] timed out, killing
[2023-03-25 18:10:16] [git] job timed out  /home/USER nil
[2023-03-25 18:10:16] [git] rc=0, signal=9
[2023-03-25 18:10:17] [git] running job with timeout 300ms
[2023-03-25 18:10:17] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
[2023-03-25 18:10:17] [git] timed out, killing
[2023-03-25 18:10:17] [git] job timed out  /home/USER nil
[2023-03-25 18:10:17] [git] rc=0, signal=9

Clean room run

When run clear; nvim --clean -nu /tmp/tmp.BDxI00kn0u/nvt-min.lua I think I got 5 or so zombies of the git. No logs were produced really.

Setup

0.9.0-dev-d3355ad
Linux Kubuntu 22.04.1 LTS
Git path: ~/.git
CWD: ~/.config/nvim

[alex-courtis]

When run clear; nvim --clean -nu /tmp/tmp.BDxI00kn0u/nvt-min.lua I think I got 5 or so zombies of the git. No logs were produced really.

Zombie termination is outstanding: #1974 That will be an experimental feature for some time. 5 zombies looks correct: git integration is disabled after 5 failures.

[2023-03-25 18:10:16] [git] running job with timeout 300ms
[2023-03-25 18:10:16] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
[2023-03-25 18:10:16] [git] timed out, killing
[2023-03-25 18:10:16] [git] job timed out  /home/USER nil
[2023-03-25 18:10:16] [git] rc=0, signal=9

It looks like it's working as intended. As an experiment, please set git.timeout to a very large number e.g. 10000ms

That should isolate timeouts from functionality problems.

[alex-courtis]

Please note that the above branch has been merged: please test with master.

[hinell]

@alex-courtis I've set timeout to 10000. After toggling nvim-tree it just hanged entire nvim instance.

With timeout set to 300 and hitting shift+R repeatedly I got several git hanged up (zombie). They all started sequentially with "disk sleep" message.

[alex-courtis]

I've set timeout to 10000. After toggling nvim-tree it just hanged entire nvim instance.

It looks like we're getting git failures that aren't being reported. What happens when you run this at the tree-root and at the repo root.

git --no-optional-locks status --porcelain=v1 --ignored=matching -u

Does this occur for all repos?

[alex-courtis]

# ~/.cache/nvim/nvim-tree.log
[2023-03-25 18:09:47] [git] { "git", "-C", "/home/USER/.config/nvim", "rev-parse", "--show-toplevel" }
/home/USER

/home/USER is a little concerning: it looks like the repo root (toplevel) might be your home directory. Is your home directory a git repo?

git status for your home directory may take a very long time - longer than 10000ms

[hinell]

@alex-courtis Yes, the git root is ~/.git, but pwd of nvim isn't at the ~/. I've installed and tested neo-tree plugin and it was quick at updating file statutes, though it has serious RAM issues. May be you look at their implementation of git status interop?

[alex-courtis]

Yes, the git root is ~/.git, but pwd of nvim isn't at the ~/.

That's intended behaviour: enumerating the git toplevel, for git files whose repo is outside the cwd.

What is the user time?

cd /home/USER
time git --no-optional-locks status --porcelain=v1 --ignored=matching -u

Having your entire home directory as a git repo sounds like it would cause performance issues. If you're using it to version control your dotfiles there are many tools to do this without needing your home to be a git repo: https://wiki.archlinux.org/title/Dotfiles

I use rcm, however there are better solutions.

[hinell]

That's intended behavior: enumerating the git toplevel, for git files whose repo is outside the cwd.

That's not on the nvim-tree, it's because I'm checked out at the subfolder.

having your entire home directory as a git repo

Nope, I don't have entire home dir as a git repo. Only chosen files and subdirs. In fact, checking out my ~/ is faster than tha many forks.

What is the user time?

0.88s user 1.24s system 34% cpu 6.126 total

[alex-courtis]

0.88s user 1.24s system 34% cpu 6.126 total

That... is reasonable. It seems git is looking at only !ignored, !exclude etc. It's not instant, but still quick.

Attempting replication.

[hinell]

@alex-courtis I can tell you that the list of files git spews out after running that command is pretty big by my standards...

[alex-courtis]

@alex-courtis I can tell you that the list of files git spews out after running that command is pretty big by my standards...

Interesting. Order of magnitude?

[hinell]

Basically entire ~/** subfolder lol. This is because untracked files are listed.

[alex-courtis]

This is because untracked files are listed.

Related #1931

A solution may involve better unlisted handling.

[alex-courtis]

I'm not able to replicate. Attempted with git repo in ~/.local/share which is 296G .gitignore

**/*

git repo ~/.local/share/some-repo

open nvim in some-repo toplevel is ~/.local/share/some-repo ~/.local/share is not enumerated. Working as expected.

non repo ~/.local/share/non-repo

open nvim in non-repo toplevel is ~/.local/share ~/.local/share is enumerated, with ignored listed, ~3ms Working as expected.

[alex-courtis]

@hinell please help me reproduce:

1. ~/.gitconfig
2. ~/.gitignore
3. replication instructions:
   1. location of directory
   2. contents of directory
      1. is it a repo?
      2. a subdirectory of a repo?
      3. multiple nested repos up to ~ ?
   3. directory nvim was opened from
   4. cwd of nvim

Full logs and nvt-min.lua would be gratefully appreciated.

[alex-courtis]

Related #1837

May be a pragmatic solution if we cannot replicate.

[alex-courtis]

@hinell there have been significant fixes/enhancements recently RE git

Please re-test with latest master.

[hinell]

@alex-courtis Hi. I'm busy with migrating my dot files to a separate folder and I'm extensively using stow for that now. The last update broke api.config.mappings.default() function again - it doesn't exist.

Please, be careful with apis like that.

Starting with 920868d in huge repos like one in $HOME/.git it still does nothing. No icon shown and process still produces zombies.

[alex-courtis]

Starting with 920868d in huge repos like one in $HOME/.git it still does nothing. No icon shown and process still produces zombies.

That's looking better. We're not seeing the huge number any more.

I do expect some performance issues with a very large cwd such as $HOME

There have been some recent improvements around ignored files/directories.

Are you ignoring all the files/directories in $HOME that are not version controlled? Does git status show nothing to commit, working tree clean when there are no changes to version controlled files?

[alex-courtis]

It's not recommended best practice to directly version control $HOME: https://wiki.archlinux.org/title/Dotfiles

Using tools or the (more complex) bare repository approach is a better experience.

I use rcm and I've heard good things about yadm.

[alex-courtis]

Please log git operations and examine the commands being executed.

There are 2 startup executions: toplevel and show untracked. Following that there will be many status executions.

An example from my dotfiles repo:

[2023-08-21 15:51:48] [git] { "git", "-C", "/home/alex/.dotfiles", "rev-parse", "--show-toplevel" }
/home/alex/.dotfiles
[2023-08-21 15:51:48] [git] { "git", "-C", "/home/alex/.dotfiles", "config", "status.showUntrackedFiles" }
[2023-08-21 15:51:48] [git] running job with timeout 800ms
[2023-08-21 15:51:48] [git] git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
 M config/nvim/lua/amc/plugins/nvt.lua
!! config/nvim/tags
[2023-08-21 15:51:48] [git] done
[2023-08-21 15:51:48] [git] job success    /home/alex/.dotfiles nil

Please time those executions e.g.

time git -C /home/alex/.dotfiles rev-parse --show-toplevel
/home/alex/.dotfiles
git -C /home/alex/.dotfiles rev-parse --show-toplevel  0.00s user 0.00s system 81% cpu 0.004 total
time git -C /home/alex/.dotfiles config status.showUntrackedFiles
git -C /home/alex/.dotfiles config status.showUntrackedFiles  0.00s user 0.00s system 81% cpu 0.004 total
time git --no-optional-locks status --porcelain=v1 -z --ignored=matching -u
 M config/nvim/lua/amc/plugins/nvt.lua!! config/nvim/tagsgit --no-optional-locks status --porcelain=v1 -z --ignored=matching -u  0.00s user 0.01s system 89% cpu 0.008 total

Goal of investigation: are the git commands slow outside of nvim?

[hinell]

@alex-courtis >It's not recommended best practice to directly version control $HOME You already said that before in April 2023 this year. I'm fully aware of this problem so that's why I've switched to GNU Stow to manage dotfiles.

Soon I won't be able to report on this issue cause I've almost finished my migraiton.

[alex-courtis]

Soon I won't be able to report on this issue cause I've almost finished my migraiton.

I hope the migration runs smoothly for you.

As we can't do anything further on this issue I'll close it down. Please do open a new issue if you encounter any git issues in the future.

[hinell]

Finally, I've finished my migration.

I'm not able to replicate. Attempted with git repo in ~/.local/share which is 296G .gitignore

@alex-courtis The easiest way you can replicate it by going into $HOME and

cd $HOME
git init .
nvim