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

Question

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

hinell opened this issue a year ago · comments

Neovim-tree-fails-to-display-git-info-2023-02-03_00.36.00.mp4.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

        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

[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

... <git --no-optional ...> repeated several times

Alexander Courtis commented a year ago

@hinell ^

hinell · Answer 1 · Fri Feb 03 2023 07:12:49 GMT+0800 (China Standard Time)

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.

Tillman Jex · Answer 2 · Sat Feb 04 2023 05:32:16 GMT+0800 (China Standard Time)

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.

Tillman Jex · Answer 3 · Sat Feb 04 2023 05:34:52 GMT+0800 (China Standard Time)

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.

Alexander Courtis · Answer 4 · Sat Feb 04 2023 12:38:06 GMT+0800 (China Standard Time)

Thanks for the diagnostics @tjex

I await the results with interest...

Alexander Courtis · Answer 5 · Sat Feb 04 2023 14:03:20 GMT+0800 (China Standard Time)

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

hinell · Answer 6 · Sat Feb 04 2023 17:23:31 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 7 · Sun Feb 05 2023 09:42:01 GMT+0800 (China Standard Time)

I've uploaded demo-video, checkout.

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

Alexander Courtis · Answer 8 · Sun Feb 05 2023 14:01:37 GMT+0800 (China Standard Time)

@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 · Answer 9 · Sun Feb 05 2023 20:33:19 GMT+0800 (China Standard Time)

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

hinell · Answer 10 · Sun Feb 05 2023 21:21:58 GMT+0800 (China Standard Time)

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

NvimTree-clear-minconfig-2023-02-05_16.13.18.mov

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

hinell · Answer 11 · Sun Feb 05 2023 23:37:08 GMT+0800 (China Standard Time)

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?

Alexander Courtis · Answer 12 · Mon Feb 06 2023 07:50:35 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 13 · Mon Feb 06 2023 07:56:41 GMT+0800 (China Standard Time)

@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 · Answer 14 · Tue Feb 07 2023 16:32:45 GMT+0800 (China Standard Time)

@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.

Alexander Courtis · Answer 15 · Sat Feb 11 2023 11:49:43 GMT+0800 (China Standard Time)

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.

hinell · Answer 16 · Mon Mar 06 2023 03:44:22 GMT+0800 (China Standard Time)

@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 · Answer 17 · Sat Mar 25 2023 23:52:27 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 18 · Mon Mar 27 2023 08:08:58 GMT+0800 (China Standard Time)

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.

Alexander Courtis · Answer 19 · Mon Mar 27 2023 08:23:59 GMT+0800 (China Standard Time)

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

hinell · Answer 20 · Tue Mar 28 2023 02:56:58 GMT+0800 (China Standard Time)

@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.

Alexander Courtis · Answer 21 · Tue Mar 28 2023 08:41:21 GMT+0800 (China Standard Time)

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?

Alexander Courtis · Answer 22 · Tue Mar 28 2023 08:46:47 GMT+0800 (China Standard Time)

# ~/.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 · Answer 23 · Tue Mar 28 2023 15:51:04 GMT+0800 (China Standard Time)

@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?

Alexander Courtis · Answer 24 · Mon Apr 03 2023 10:51:55 GMT+0800 (China Standard Time)

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 · Answer 25 · Tue Apr 04 2023 23:34:30 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 26 · Fri Apr 07 2023 07:24:33 GMT+0800 (China Standard Time)

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 · Answer 27 · Fri Apr 07 2023 23:07:18 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 28 · Sat Apr 08 2023 09:25:15 GMT+0800 (China Standard Time)

@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 · Answer 29 · Sat Apr 08 2023 14:10:39 GMT+0800 (China Standard Time)

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

Alexander Courtis · Answer 30 · Sun Apr 09 2023 12:17:07 GMT+0800 (China Standard Time)

This is because untracked files are listed.

Related #1931

A solution may involve better unlisted handling.

Alexander Courtis · Answer 31 · Mon Apr 10 2023 12:35:46 GMT+0800 (China Standard Time)

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.

Alexander Courtis · Answer 32 · Mon Apr 10 2023 12:40:53 GMT+0800 (China Standard Time)

@hinell please help me reproduce:

~/.gitconfig
~/.gitignore
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.

Alexander Courtis · Answer 33 · Tue Apr 11 2023 12:15:29 GMT+0800 (China Standard Time)

Related #1837

May be a pragmatic solution if we cannot replicate.

Alexander Courtis · Answer 34 · Sun Aug 20 2023 13:55:45 GMT+0800 (China Standard Time)

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

Please re-test with latest master.

hinell · Answer 35 · Sun Aug 20 2023 22:02:28 GMT+0800 (China Standard Time)

@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.

Alexander Courtis · Answer 36 · Mon Aug 21 2023 09:07:48 GMT+0800 (China Standard Time)

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?

Alexander Courtis · Answer 37 · Mon Aug 21 2023 11:51:56 GMT+0800 (China Standard Time)

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.

Alexander Courtis · Answer 38 · Mon Aug 21 2023 13:58:06 GMT+0800 (China Standard Time)

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 · Answer 39 · Mon Aug 21 2023 20:01:56 GMT+0800 (China Standard Time)

@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.

Alexander Courtis · Answer 40 · Tue Aug 22 2023 07:17:40 GMT+0800 (China Standard Time)

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 · Answer 41 · Fri Aug 25 2023 21:52:49 GMT+0800 (China Standard Time)

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

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

Description

Neovim version

Operating system and version

nvim-tree version

Minimal config

Steps to reproduce

Expected behavior

Actual behavior

Clean room run

Setup

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

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

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

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