neogit
neogit copied to clipboard
can't commit from nvim client
Description
When Remote editing, can't commit from the nvim client.
Neovim version
NVIM v0.8.0-1210-gd367ed9b2 Build type: Release LuaJIT 2.1.0-beta3 Compiled by runner@fv-az505-656
Operating system and version
Linux mint 21
Steps to reproduce
- run a nvim headless server
- run a nvim client instance connect to that server
- open a git repo
- run :Neogit , then
c
, thenc
- get a error
Expected behavior
commit without error
Actual behavior
can't open commit edit buffer
Error detected while processing command line:
E5108: Error executing lua Vim:connection failed: connection refuse
d
stack traceback:
[C]: in function 'sockconnect'
...vim/site/pack/packer/start/neogit/l
ua/neogit/lib/rpc.lua:31: in fun
ction 'connect'
...vim/site/pack/packer/start/neogit/lua/neogit/lib/rpc.lua:
25: in function 'create_connection'
...nvim/site/pack/packer/start/neogit/lua/neogit/client.lua:
51: in function 'client'
[string ":lua"]:1: in main chunk
Command running for: 1999.55 ms
Minimal config
vim.cmd([[set runtimepath=$VIMRUNTIME]])
vim.cmd([[set packpath=/tmp/nvim/site]])
local package_root = "/tmp/nvim/site/pack"
local install_path = package_root .. "/packer/start/packer.nvim"
local function load_plugins()
require("packer").startup({
{
"wbthomason/packer.nvim",
{
"TimUntersberger/neogit",
requires = {
{ "nvim-lua/plenary.nvim" },
{ "sindrets/diffview.nvim" },
},
config = function()
print("loaded neogit")
require("neogit").setup()
end,
},
},
config = {
package_root = package_root,
compile_path = install_path .. "/plugin/packer_compiled.lua",
display = { non_interactive = true },
},
})
end
if vim.fn.isdirectory(install_path) == 0 then
print("Installing neogit and dependencies.")
vim.fn.system({ "git", "clone", "--depth=1", "https://github.com/wbthomason/packer.nvim", install_path })
end
load_plugins()
require("packer").sync()
It seems the origin nvim binary cilent working right, but other GUI client has this issue like nvim-qt, neovide.
This can actually be reproduced with --remote-ui
Server:
nvim --listen 127.0.0.1:7777 --headless
Client:
nvim --server 127.0.0.1:7777 --remote-ui
Error:
hint: Waiting for your editor to close the file... Error detected while processing command line:
E5108: Error executing lua Vim:connection failed: connection refused
stack traceback:
[C]: in function 'sockconnect'
...vim/site/pack/packer/start/neogit/lua/neogit/lib/rpc.lua:31: in function 'connect'
...vim/site/pack/packer/start/neogit/lua/neogit/lib/rpc.lua:25: in function 'create_connection'
...nvim/site/pack/packer/start/neogit/lua/neogit/client.lua:51: in function 'client'
Note this bug seems exclusive to using a tcp connection with --listen. Using a pipe connection works correctly e.g.:
nvim --listen /tmp/test2.sock --headless
and
nvim --server /tmp/test2.sock --remote-ui
Perhaps there is some bug with neovim with mixing pipe and tcp sockets?
Edit: This is because v:servername
is being set to the --listen
argument, however setting the sockconnect
argument to tcp
doesn't resolve the issue either (looks like the client tries to connect and does nothing?). I'd have to look into it more to give more details.
Is there another workaround for this as I have to use a tcp connection to connect to the remote nvim therefore I cannot use a socket.
I'm also experiencing this issue. My current workaround is to use vim-fugitive
to do the actual commit. So essentially I use Neogit for all my diffviews and staging and unstaging files. I am using nvim-remote.nvim
to run neovim in a dev container using Docker and DevPod. Because my setup is still technically local development, I sometimes just exit the remote session to do all my git operations. Overall though, I would like to not have to rely on fugitive and not have to exit my remote session.
@patrickTumulty I have just now realized another way to combine both connection methods. I use socat
inside my dev container to redirect the TCP connection to a /tmp/nvim.sock
that I then use in nvim --listen /tmp/nvim.sock --headless
. So far, it seems to work.
Same issue here, using neovide connected to a remote docker container cause similar issue