Windows Neotree cwd and Gitsigns prevents Neovim exit (LazyVim) #1027
Comments
|
Please remove lazy.nvim from the repro steps. Also note I don't have access to Windows, so it is unlikely anyone will fix this. |
Unfortunately it's got to do with the LazyVim integration. Without LazyVim, the error doesn't happen. But it also only happens in LazyVIm if gitsigns is enabled, and the commit is later than cdfcd9d.
Yeah, being on Windows is more trouble than its worth. I'm strongly considering moving to Linux, but unfortunately still need Windows for university stuff. From what I can tell, gitsigns is preventing Neovim from closing because it thinks there's still a git repo open. I understand not being able to fix it -- I can just keep it pinned to the commit that still works, if there is no obvious way to resolve it. |
|
I am on macOS and have had separate issues (startup backtrace) on anything after I bring it up here because of the common denominator of the commit, even though we have completely different behaviors. I have opened this discussion item on the LazyVim side because I doubt I have enough info to open a proper issue. |
|
Let's not conflate all backtrace issues into one. From what I can tell they are separate issues. |
|
Hello, I'm running into this issue as well. It happens if using gitsigns without a manager, and just doing the normal setup song + dance. I noticed that there is always a git.exe instance in the background that just refuses to close. If there was a way we could force gitsigns to disengage or "close" these git instances during the As it stands now, even |
|
@bruxisma would you be able to create a reproducible version that doesn't use LazyVim, then? I have noticed that some tasks don't close when Neovim does, so it's possibly a Neovim issue, not just restricted to Gitsigns. For me, I've noticed I've needed to manually stop the lsp servers under the nvim process from Task Manager. LuaLS especially likes to keep itself open. For now, you don't need to uninstall Gitsigns, you could just pin it to the commit before it stopped working. |
|
Apparently someone had a similar issue and was resolved by removing a call to If anyone can confirm this, that would be helpful. Otherwise, this still needs to be debugged by someone who can reproduce the issue. |
|
I think I can mostly confirm this. I say mostly, because I did not scour the Lazy source code to find an explicit My issues, which were an intermittent once every other or three startup stacktraces, went away when I made the below material change (removing the The normal pattern, mostly, is to duplicate the setup inside a |
|
Thank you @sinkr . This gives me a good idea where to look for issues. |
@Kayzels So I actually don't use LazyVim at all. I use lazy.nvim as a package manager. When I was writing my comment earlier, I actually thought LazyVim was a typo that you had used to refer to lazy.nvim (I wrote my issue at 3:30 AM my time as I was pulling a late night and was tired of running into this issue) That said, the lazy.nvim configuration I use for gitsigns is {
"lewis6991/gitsigns.nvim",
event = "VeryLazy",
opts = {
signs = {
changedelete = { text = "" },
delete = { text = "" },
change = { text = "" },
add = { text = "" },
},
},
},Hopefully this can add some additional information to what @sinkr showed above. |
|
No not really. Need to be able to reproduce this without lazy, otherwise I consider this a lazy issue. I swear VeryLazy causes more problems than it solves (none). |
|
As I stated in my initial comment, I was able to replicate this happening without using lazy.nvim (or VeryLazy as an event loader). I had manually cloned, manually loaded, and manually called setup() and was still having the issue. When VeryLazy is removed, a background git.exe instance is always executing. When it is present it only happens if I'm editing in a git repository (which isn't always. sometimes I have scratch files I work on). That said, as I'm writing this comment, I do wonder if maybe the |
|
Ok, after spending some time testing, With that said, I was able to narrow down some of the behavior. This only appears (for me) to happen in files/buffers where:
I'm unable to get either case to reliably happen separate from each other. |
|
Thank you @bruxisma for the detailed troubleshooting here. This makes a lot more sense and I can confirm I'm having similar problems. I've pinned to cdfcd9d and can confirm this does not have the freezing issues. I know its been stated numerous times in this issue to remove all lazy/LazyVim references to isolate the variables, but just adding my troubleshooting steps when I initially ran into this problem (had no idea it was possibly related to gitsigns):
Again, I know this is not a sufficient troubleshooting as already discussed in this issue, but at least maybe this can help other people stepping through similar logic to find some common themes and they can help us gather more information. Unfortunately I'm not home today to work on this so I can't offer much in the way of finding a fix. |
Is there anything preventing you from producing a testcase (as per the issue template)? Otherwise, this information is much less helpful than you think. Without being able to properly debug this, anything can be happening. I'll copy the steps here for convenience. Here is the template for a minimal init.lua: for name, url in pairs{
gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
-- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
} do
local install_path = vim.fn.fnamemodify('gitsigns_issue/'..name, ':p')
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system { 'git', 'clone', '--depth=1', url, install_path }
end
vim.opt.runtimepath:append(install_path)
end
require('gitsigns').setup{
debug_mode = true, -- You must add this to enable debug messages
-- ADD GITSIGNS CONFIG THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUE
}
-- ADD INIT.LUA SETTINGS THAT IS _NECESSARY_ FOR REPRODUCING THE ISSUEThis init.lua can be used by running Provide this along side instructions like:
If this is provided and I am able to reproduce this, then I can debug it and fix it. |
|
@lewis6991 sure I will work on this today, I'm a bit limited on what I can test at work but I should be able to reproduce the issues here. |
|
@lewis6991 as requested Content of repro config for name, url in pairs({
gitsigns = "https://github.com/lewis6991/gitsigns.nvim",
}) do
local install_path = vim.fn.fnamemodify("gitsigns_issue/" .. name, ":p")
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
end
vim.opt.runtimepath:append(install_path)
end
require("gitsigns").setup({
debug_mode = true, -- You must add this to enable debug messages
})Steps to reproduce:
The above steps could maybe be combined to be a bit less verbose but wanted to be explicit about separate commands. NOTE: I was not able to reproduce the issue on WSL with the above steps. |
|
Thanks. I was hoping that since you can reproduce this in WSL that I could repro it on Mac, but I couldn't. Looks like I need to build a VM to try and repro this. EDIT: Looks like WSL doesn't work in MacOS VM's as it doesn't support nested virtualisation. |
Just to clarify I can not repro in WSL :) I'm happy to try and take a stab at it when I get home, I have a Windows machine I can work on. Running the above steps, I was not able to find any debug/log file for gitsigns -- is there something else I need to enable in the options to output it? |
|
The logs are all internal to the session. You can see them by running
Ah sorry, I misread. This must indeed be a window issue. |
|
Also the Something about that function is causing issues and might also explain why some users are getting similar problems when calling setup twice is it will invoke |
|
As maybe an exercise in futility, I edited the +local log_file = vim.uv.cwd() .. '/gitsigns.log'
-- If called in a callback then make sure the callback defines a __FUNC__
-- variable which can be used to identify the name of the function.
--- @param obj any
--- @param lvl integer
local function cprint(obj, lvl)
...
table.insert(M.messages, msg2)
+ local f = assert(io.open(log_file, 'ab'))
+ local sec = vim.uv.gettimeofday() -- I'm dumb, these are seconds
+ f:write(sec .. ' ' .. msg2)
+ f:write('\n')
+ f:flush()
+ f:close()
endI don't see much here but maybe you'll see something useful.
EDIT: never mind I'm an idiot, those were seconds not ms... 🤦 Log output |
|
Running on debug mode gives which is referencing this line. Easier reproduction steps: Run for name, url in pairs({
gitsigns = "https://github.com/lewis6991/gitsigns.nvim",
}) do
local install_path = vim.fn.fnamemodify("gitsigns_issue/" .. name, ":p")
if vim.fn.isdirectory(install_path) == 0 then
vim.fn.system({ "git", "clone", "--depth=1", url, install_path })
end
vim.opt.runtimepath:append(install_path)
end
require("gitsigns").setup({
debug_mode = true, -- You must add this to enable debug messages
})
vim.cmd[[tabnew]]
vim.cmd[[tcd ..]]Creating git repos, commiting files and the other stuff is not necessary, just run the above anywhere and quit neovim. |
|
Minimaler repro: Run local watcher = assert(vim.uv.new_fs_event())
watcher:start('.', {}, function()
print('hello')
end)
watcher:stop()
watcher:start('.', {}, function()
print('bye')
end) |
|
Can people try #1031 |
Description
This happens specifically with a LazyVim setup, but they cannot reproduce it, so checking if there might be more luck here.
Using Neotree, you can change the current working directory by pressing
.. Doing this in a git repo, or changing to git repo using it, causes Neovim to freeze on exit. Importantly, it only seems to happen if the Neovim is started in a folder that is a git repo.Maybe its having an issue with the cwd update? The maintainers of the LazyVim repo couldn't reproduce, so possibly its Windows specific? I noticed that the last working commit that didn't cause this was cdfcd9d - it broke from 720061a.
Any non-git folders aren't affected, and using an older version of gitsigns doesn't cause the issue.
Unfortunately, because it's happening with LazyVim, the repro needs to include that, so it's not particularly small any more.
Neovim version
NVIM v0.10.0 Release
Operating system and version
Windows 10 Pro 22H2 19045.3803
Expected behavior
Neovim should exit without freezing the terminal.
Actual behavior
Neovim hangs on exit.
Nvim_not_closing_gitsigns.mp4
Minimal config
Steps to reproduce
repro.lua(or `minimal.lua, but then you need to update the nvim command.git initnvim --clean -u repro.luarepro.luafile from Neotree, navigating to it by typing:Neotree.Backspaceto go up a folder.repro.luafile.Backspaceto see a list of the directories including the created one containing therepro.luafile..on the folder that contains therepro.luafile.repro.luafile.:qa.Gitsigns debug messages
The text was updated successfully, but these errors were encountered: