Closed lewis6991 closed 5 months ago
unfortunately i already reproduced the error even with this version..
Error executing vim.schedule lua callback: ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:85: The coroutine failed with this message: ...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/hunks.lua:174: Invalid hunk with untracked=true hunk="@@ -25,1 +25,1 @@"
stack traceback:
[C]: in function 'assert'
...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/hunks.lua:174: in function 'calc_signs'
...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:52: in function 'apply_win_signs0'
...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:76: in function 'apply_win_signs'
...pack/packer/start/gitsigns.nvim/lua/gitsigns/manager.lua:517: in function 'fn'
...ack/packer/start/gitsigns.nvim/lua/gitsigns/debounce.lua:68: in function 'update'
...pack/packer/start/gitsigns.nvim/lua/gitsigns/watcher.lua:101: in function <...pack/packer/start/gitsigns.nvim/lua/gitsigns/watcher.lua:63>
stack traceback:
[C]: in function 'error'
...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:85: in function 'cb'
...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:127: in function <...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:126>
[C]: in function 'resume'
...e/pack/packer/start/diffview.nvim/lua/diffview/async.lua:193: in function 'step'
...e/pack/packer/start/diffview.nvim/lua/diffview/async.lua:247: in function 'notify_all'
...e/pack/packer/start/diffview.nvim/lua/diffview/async.lua:222: in function 'step'
...e/pack/packer/start/diffview.nvim/lua/diffview/async.lua:399: in function <...e/pack/packer/start/diffview.nvim/lua/diffview/async.lua:391>
i do believe it's related to how slow neovim is. right now i'm making a big port, the lsp is very slow, many build errors and so on.
this was again from diffview.
I've significantly reworked this, so the buffer contents come from the direct git object as opposed to running the more abstract git show <revision>:<path>
command. This should ensure the buffer contents always matches the tracked object name, even if it's not up-to-date because of other processes.
@emmanueltouzery have you had a chance to test this?
yes, I'm using it. I did not reproduce the issue since switching to it. However I have finished my huge refactor and I'm less likely to reproduce the issue right now. Even before this refactor I would reproduce the issue regularly, but not as readily. Maybe once per week, give or take. I intend to stay on the branch and report if I reproduce the issue again.
However I have finished my huge refactor and I'm less likely to reproduce the issue right now.
Even with your system being pushed with so many git operations, gitsigns shouldn't error. What's useful about your situation is that you can reproduce this issue much more easily than others.
@emmanueltouzery any updates? Have you been able to test this any more?
i'm using this branch all the time. i didn't reproduce the issue anymore, but it's true that i'm not having the extreme temporary situation that i had back then. on the other hand, i had been reproducing the issue like once every 10 days at least before, and i haven't seen it yet on this branch.
Thanks for letting me know. I guess we can merge this.
Fixes #847