Closed hinell closed 1 year ago
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.
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.
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.
Thanks for the diagnostics @tjex
I await the results with interest...
Not a solution, however I am investigating / warning about (timed out) zombies: #1970
@alex-courtis @tjex I've uploaded demo-video, checkout.
I've uploaded demo-video, checkout.
Unfortunately that video "file is corrupt" and cannot play. You might want to try https://asciinema.org/
@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.
@alex-courtis Checkout video againt. I've reuploaded it. The previous one was working well on chrome.
_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.
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 usualWhy doesn't NvimTree checks git state when it's NvimTreeFocus
ed or toggled btw?
Why doesn't NvimTree checks git state when it's
NvimTreeFocus
ed or toggled btw?
With the default configuration git state is updated upon:
@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.
@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.
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 innvim
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 ^
@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!
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
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.
0.9.0-dev-d3355ad
Linux Kubuntu 22.04.1 LTS
Git path: ~/.git
CWD: ~/.config/nvim
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.
Please note that the above branch has been merged: please test with master.
@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.
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?
# ~/.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
@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?
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.
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
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.
@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 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?
Basically entire ~/**
subfolder lol. This is because untracked files are listed.
This is because untracked files are listed.
Related #1931
A solution may involve better unlisted handling.
I'm not able to replicate. Attempted with
git repo in ~/.local/share
which is 296G
.gitignore
**/*
~/.local/share/some-repo
open nvim in some-repo
toplevel is ~/.local/share/some-repo
~/.local/share
is not enumerated.
Working as expected.
~/.local/share/non-repo
open nvim in non-repo
toplevel is ~/.local/share
~/.local/share
is enumerated, with ignored listed, ~3ms
Working as expected.
@hinell please help me reproduce:
~/.gitconfig
~/.gitignore
~
?Full logs and nvt-min.lua
would be gratefully appreciated.
Related #1837
May be a pragmatic solution if we cannot replicate.
@hinell there have been significant fixes/enhancements recently RE git
Please re-test with latest master.
@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.
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?
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.
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?
@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.
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.
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
https://user-images.githubusercontent.com/8136158/216818824-cb9f2a13-2167-4103-8f30-8bf849f5bbab.mov
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
Operating system and version
Ubuntu 22.04.1 LTS
nvim-tree version
16a0e3c
Minimal config
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 ...