Closed xz47sv closed 1 month ago
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 to incremental_iter. If it is incomplete and doesn't contain a line starting with filename an error will occur.
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.
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 to incremental_iter. If it is incomplete and doesn't contain a line starting with filename an error will occur.
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 print(vim.inspect(data_lines))
on top of incremental_iter
I can get this output in neovim:
{ "7178d1a430dcfff8a4c92d78b9e39e0297a779c0 1 1 1216", "" }
Error executing luv callback:
...igns/gitsigns_issue/gitsigns//lua/gitsigns/git/blame.lua:131: attempt to index a nil value
stack traceback:
...igns/gitsigns_issue/gitsigns//lua/gitsigns/git/blame.lua:131: in function 'incremental_iter'
...igns/gitsigns_issue/gitsigns//lua/gitsigns/git/blame.lua:171: in function 'process_incremental'
...igns/gitsigns_issue/gitsigns//lua/gitsigns/git/blame.lua:229: in function <...igns/gitsigns_issue/gitsigns//lua/gitsigns/git/blame.lua:228>
Press ENTER or type command to continue
{ "author Lewis Russell", "author-mail <lewis6991@gmail.com>", "author-time 1720692260", "author-tz +0100", "committer Lewis Russell", "committer-mail <lewis6991@gmail.com>", "committer-time 1720692260", "committer-tz +0100", "summary fix: add nil check", "boundary", "filename doc/gitsigns.txt", "" }
So yes, it does end on a newline, just not the right one.
Can you test #1087?
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