Skip to content
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

Gitsigns fails to run git --version #948

Closed
no-more-secrets opened this issue Feb 25, 2024 · 8 comments · Fixed by #962 or #1002
Closed

Gitsigns fails to run git --version #948

no-more-secrets opened this issue Feb 25, 2024 · 8 comments · Fixed by #962 or #1002
Labels
bug Something isn't working unable to reproduce Unable to reproduce problem

Comments

@no-more-secrets
Copy link

Description

I'm seeing this consistently now when I load my editor session (I'm running the latest nvim 0.9.5 and the latest gitsigns):

Error executing luv callback:
...e/pack/packer/start/gitsigns.nvim/lua/gitsigns/async.lua:85: The coroutine failed with this message: ...ite/pack/packer/start/gitsigns.nvim/lua/gitsigns/git.lua:123: Unexpected output:
stack traceback:
        [C]: in function 'assert'
        ...ite/pack/packer/start/gitsigns.nvim/lua/gitsigns/git.lua:123: in function '_set_version'
        ...ite/pack/packer/start/gitsigns.nvim/lua/gitsigns/git.lua:137: in function 'git_command'
        ...ite/pack/packer/start/gitsigns.nvim/lua/gitsigns/git.lua:401: in function 'new'
        ...ite/pack/packer/start/gitsigns.nvim/lua/gitsigns/git.lua:840: in function 'new'
        .../pack/packer/start/gitsigns.nvim/lua/gitsigns/attach.lua:290: in function 'fn'
        ...ack/packer/start/gitsigns.nvim/lua/gitsigns/debounce.lua:68: in function 'attach_throttled'
        .../pack/packer/start/gitsigns.nvim/lua/gitsigns/attach.lua:435: in function <.../pack/packer/start/gitsigns.nvim/lua/gitsigns/attach.lua:434>
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 'on_exit'
        ...acker/start/gitsigns.nvim/lua/gitsigns/system/compat.lua:256: in function <...acker/start/gitsigns.nvim/lua/gitsigns/system/compat.lua:226>

It happens every time I open my editor session. It's been happening for a while now, hope that we can fix this.

When I run git --version on my system I get the expected output:

git version 2.25.1

and when I go into git.lua into the _set_version function where it is failing and I hard code that, then the issue goes away.

Seems this command is flaky:

  local obj = asystem({ 'git', '--version' })

seems hard to imagine that it is anything in my environment that could be causing that, given how simple the command is.

Neovim version

0.9.5

Operating system and version

Linux64 Pop!_OS 20.04

Expected behavior

no exception

Actual behavior

exception given above

Minimal config

I can provide one if needed

Steps to reproduce

I'm hoping someone can look at the error/code and determine what is going on without needing detailed steps. But if you need detailed steps I can try to provide them when I have time.

Gitsigns debug messages

No response

@no-more-secrets no-more-secrets added the bug Something isn't working label Feb 25, 2024
@lewis6991
Copy link
Owner

Can you edit the code and print the contents of obj?

@no-more-secrets
Copy link
Author

@lewis6991 Here is the code I inserted:

  local obj = asystem({ 'git', '--version' })
  -- new code below.
  local f = assert( io.open( 'gitversion.txt', 'a+' ) )
  f:write( 'obj.stderr:\n[' .. tostring( obj.stderr ) .. ']\n' )
  f:write( 'obj.stdout:\n[' .. tostring( obj.stdout ) .. ']\n' )
  f:write( 'obj keys/values:\n' )
  for k, v in pairs( obj ) do
    f:write( 'k=[' .. tostring( k ) .. '], v=[' .. tostring( v ) .. ']\n' )
  end
  f:write( '----------------------------------------------------\n' )

As you can see I added [ and ] in there so that you could see the exact spacing content of the printed values. Then I open my editor with a couple of files in separate tabs (as usual). For most of the buffers git --version succeeds; in those cases it prints the following:

----------------------------------------------------
obj.stderr:
[]
obj.stdout:
[git version 2.25.1
]
obj keys/values:
k=[stdout], v=[git version 2.25.1
]
k=[stderr], v=[]
k=[code], v=[0]
k=[signal], v=[0]
----------------------------------------------------

But then for at least one buffer it fails, and in those cases prints the following:

----------------------------------------------------
obj.stderr:
[]
obj.stdout:
[]
obj keys/values:
k=[stdout], v=[]
k=[stderr], v=[]
k=[code], v=[0]
k=[signal], v=[0]
----------------------------------------------------

let me know if you need any more info.

@lewis6991
Copy link
Owner

Looks like it's erroring on the call that's returning empty.

Honestly I don't really know how to proceed. I can't reproduce this so there's no way I can debug it.

@lewis6991 lewis6991 added the unable to reproduce Unable to reproduce problem label Feb 25, 2024
@no-more-secrets
Copy link
Author

@lewis6991 As a hint, I think it only happens when I open a large number of files at once. I have an editor session that opens around 60 buffers (spread throughout 15 tabs). Perhaps gitsigns is trying to spawn subprocesses for each of those all at the same time, and something in the async/subprocess pipe mechanism is flaking out because there are too many. In fact, if I simply have the code retry the command, that fixes it as well:

  local obj = (function()
    local o
    repeat
      o = asystem({ 'git', '--version' })
    until (#o.stdout > 0) or (#o.stderr > 0)
    return o
  end)()

Further evidence for this is that the failure doesn't tend to happen until one of the last few buffers is processed (e.g. the 58th one).

Maybe this can help you to either reproduce it or determine what the issue is.

@jedrzejboczar
Copy link

I have the same issue, it fails when git --version returns empty output and retrying fixes the problem. It seems to happen a most often when I open big fugitive.vim diffs (dd in git status window on big files). And sometimes when I start nvim with a file and immediately start moving cursor, though this seems strange.

@bugabinga
Copy link

This is really hard to reproduce. I also have had this issue, but ever since deleting and re-creating my session, it does not repro.

My only guess would be, that, since asystem delegates to vim.system on nightly, there is some race condition in it?

NVIM v0.10.0-dev-2660+g7549845e8 on WSL2

@aarondill
Copy link

I've experienced this as well on nightly, but without opening large files.

It seems to be random, but occasionally when opening recently edited files, I receive the above error.

@Willem-J-an
Copy link

I have a project where it happens consistently. If I check if line is an empty string and let it silently error out the error does not bother me anymore; the code will still run successfully the next time it tries to set the version so I prefer this as workaround over getting the error consistently on startup.

local line = vim.split(obj.stdout or '', '\n', { plain = true })[1]
  if not line or line == "" then
    err("Unable to detect git version as 'git --version' failed to return anything")
    -- eprint(obj.stderr)
    return
  end

lewis6991 added a commit that referenced this issue Apr 1, 2024
- Avoid emitting errors when the version check fails.
- Put version checking into separate module.
- Pull in upstream changes for vim.system.

Fixes: #948
Closes: #960
lewis6991 added a commit that referenced this issue Apr 1, 2024
- Avoid emitting errors when the version check fails.
- Put version checking into separate module.
- Pull in upstream changes for vim.system.

Fixes: #948
Closes: #960
lewis6991 added a commit that referenced this issue Apr 1, 2024
- Avoid emitting errors when the version check fails.
- Put version checking into separate module.
- Pull in upstream changes for vim.system.

Fixes: #948
Closes: #960
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment