I expect Gitsigns to silently not attach to Fugitive tree buffers.
Actual behavior
Gitsigns throws the following error every time you navigate to a new directory when viewing a Fugitive tree:
Error executing luv callback:
...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:85: The coroutine failed with this message: ...local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/git.lua:537: assertion failed!
stack traceback:
[C]: in function 'assert'
...local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/git.lua:537: in function 'file_info'
...local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/git.lua:405: in function 'update'
...local/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/git.lua:914: in function 'new'
...al/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/attach.lua:273: in function 'fn'
.../share/nvim/lazy/gitsigns.nvim/lua/gitsigns/debounce.lua:68: in function 'attach_throttled'
...al/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/attach.lua:420: in function <...al/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/attach.lua:419>
stack traceback:
[C]: in function 'error'
...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:85: in function 'cb'
...cal/share/nvim/lazy/gitsigns.nvim/lua/gitsigns/async.lua:127: in function 'on_exit'
/usr/local/share/nvim/runtime/lua/vim/_system.lua:300: in function </usr/local/share/nvim/runtime/lua/vim/_system.lua:270>
Minimal config
for name, url in pairs{
gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
fugitive = 'https://github.com/tpope/vim-fugitive',
} 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,
}
Steps to reproduce
mkdir gitsigns_issue
cd gitsigns_issue
git init
mkdir -p dir/subdir
touch dir/subdir/file
git add dir/subdir/file
git commit -m 'initial commit'
nvim --clean -u minimal.lua +'Gedit HEAD:'
move cursor to dir and press <CR>
At this point you should see the error above. Navigating to subdir will throw the same error, and so on.
Gitsigns debug messages
2.17 D derive: Deriving GitSignsStagedTopdelete from GitSignsTopdelete
2.23 D derive: Deriving GitSignsStagedAddNr from GitSignsAddNr
2.27 D derive: Deriving GitSignsStagedChangeNr from GitSignsChangeNr
2.34 D derive: Deriving GitSignsStagedDeleteNr from GitSignsDeleteNr
2.40 D derive: Deriving GitSignsStagedChangedeleteNr from GitSignsChangedeleteNr
2.43 D derive: Deriving GitSignsStagedTopdeleteNr from GitSignsTopdeleteNr
2.46 D derive: Deriving GitSignsStagedAddLn from GitSignsAddLn
2.50 D derive: Deriving GitSignsStagedChangeLn from GitSignsChangeLn
2.56 D derive: Could not derive GitSignsStagedDeleteLn
2.59 D derive: Deriving GitSignsStagedChangedeleteLn from GitSignsChangedeleteLn
2.62 D derive: Could not derive GitSignsStagedTopdeleteLn
2.66 D derive: Deriving GitSignsAddPreview from DiffAdd
2.73 D derive: Deriving GitSignsDeletePreview from DiffDelete
2.79 D derive: Deriving GitSignsCurrentLineBlame from NonText
2.82 D derive: Deriving GitSignsAddInline from TermCursor
2.85 D derive: Deriving GitSignsDeleteInline from TermCursor
2.88 D derive: Deriving GitSignsChangeInline from TermCursor
2.91 D derive: Deriving GitSignsAddLnInline from GitSignsAddInline
2.94 D derive: Deriving GitSignsChangeLnInline from GitSignsChangeInline
2.96 D derive: Deriving GitSignsDeleteLnInline from GitSignsDeleteInline
3.01 D derive: Deriving GitSignsDeleteVirtLn from DiffDelete
3.06 D derive: Deriving GitSignsDeleteVirtLnInLine from GitSignsDeleteLnInline
3.09 D derive: Deriving GitSignsVirtLnum from GitSignsDeleteVirtLn
68.52 D attach(1): Attaching (trigger=BufReadPost)
68.83 D get_buf_path(1): Fugitive buffer for file '/home/jamin/gitsigns_issue/' from path 'fugitive:///home/jamin/gitsigns_issue/.git//a4ccf3f674cb866b1e31f4769a15c1c71802f259/'
68.93 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 config user.name
73.53 D run_job: git --version
75.17 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
76.88 D new: Not in git repo
76.91 D attach(1): Empty git obj
99.03 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
1167.15 D attach(3): Attaching (trigger=BufReadPost)
1167.45 D get_buf_path(3): Fugitive buffer for file '/home/jamin/gitsigns_issue/dir' from path 'fugitive:///home/jamin/gitsigns_issue/.git//a4ccf3f674cb866b1e31f4769a15c1c71802f259/dir'
1167.52 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 config user.name
1170.17 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 rev-parse --show-toplevel --absolute-git-dir --abbrev-ref HEAD
1172.11 D run_job: git --no-pager --no-optional-locks --literal-pathspecs -c gc.auto=0 --git-dir /home/jamin/gitsigns_issue/.git -c core.quotepath=off ls-tree a4ccf3f674cb866b1e31f4769a15c1c7
1802f259 /home/jamin/gitsigns_issue/dir
9618.75 D cli.run: Running action 'debug_messages' with arguments {}
Description
Gitsigns throws an error after navigating to new directory when viewing a Fugitive tree (e.g., via
:Gedit HEAD:
).Neovim version
NVIM v0.10.0 Build type: Release LuaJIT 2.1.1713484068
Operating system and version
Pop!_OS 22.04 LTS x86_64
Expected behavior
I expect Gitsigns to silently not attach to Fugitive tree buffers.
Actual behavior
Gitsigns throws the following error every time you navigate to a new directory when viewing a Fugitive tree:
Minimal config
Steps to reproduce
mkdir gitsigns_issue
cd gitsigns_issue
git init
mkdir -p dir/subdir
touch dir/subdir/file
git add dir/subdir/file
git commit -m 'initial commit'
nvim --clean -u minimal.lua +'Gedit HEAD:'
dir
and press<CR>
At this point you should see the error above. Navigating to
subdir
will throw the same error, and so on.Gitsigns debug messages
Gitsigns cache
(not relevant)