-
-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Nil value error due to faulty parsing of blame #1084
Comments
I'm fairly sure (but not 100%) that the output from git-blame will always end in a newline (this can be tested by adding an assert), thus we don't need to buffer for this. But yes, that doesn't mean the full blame entry will be present in the output of each callback. |
If I add
So yes, it does end on a newline, just not the right one. |
Can you test #1087? |
works like charm, cannot reproduce the issue anymore |
Description
Sometimes when opening files the below error shows up:
Neovim version
NVIM v0.10.0 Build type: MinSizeRel LuaJIT 2.1.1710398010
Operating system and version
Alpine Linux edge
Expected behavior
No response
Actual behavior
This happens inconsistently when opening any file with no uncommited changes when trying to get blame. Happens maybe 50% of the time on my laptop, but on my desktop it took around 50 attempts to get it once. I am pretty sure this is affected by the speed of my machine and git simply not being able to pump out the blame fast enough.
The reason, I believe, is that
process_incremental
in git/blame.lua does not do any buffering, it will just split data on newlines and pass it toincremental_iter
. If it is incomplete and doesn't contain a line starting with filename an error will occur.As far as I know
vim.system
makes no guarantees about how much data is sent to the stdout callback soprocess_incremental
should wait until it finds a line starting with "filename" and only process it afterwards or not use the callback and wait for the entire output before parsing.Minimal config
Steps to reproduce
nvim --clean -u minimal.lua gitsigns_issue/gitsigns/doc/gitsigns.txt
(the file to open was chosen arbitrarily, it can be any file in any git repo)
As I mentioned, this happens inconsistently and is probably affected by
speedslowness of my machine so I wouldn't be surprised if you couldn't reproduce it, but I hope my argument above is sound enough to see the issue.Gitsigns debug messages
Gitsigns cache
No response
The text was updated successfully, but these errors were encountered: