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

bug: Clobbering GIT_SSH_COMMAND leads to problems #491

Closed
3 tasks done
ixil opened this issue Feb 5, 2023 · 1 comment · Fixed by #478
Closed
3 tasks done

bug: Clobbering GIT_SSH_COMMAND leads to problems #491

ixil opened this issue Feb 5, 2023 · 1 comment · Fixed by #478
Labels
bug Something isn't working

Comments

@ixil
Copy link

ixil commented Feb 5, 2023

Did you check docs and existing issues?

  • I have read all the lazy.nvim docs
  • I have searched the existing issues of lazy.nvim
  • I have searched the exsiting issues of plugins related to this issue

Neovim version (nvim -v)

NVIM v0.8.3 Build type: RelWithDebInfo LuaJIT 2.1.0-beta3 Features: -acl +iconv +tui

Operating system/version

Windows 11

Describe the bug

Lazy specifies the GIT_SSH_COMMAND env argument, as far as I can tell in order to specify the -oBatchMode flag.
However, I have specified a GIT_SSH (basically equivalent to GIT_SSH_COMMAND for using plink.exe. The current method in lazy.nvim means all git (that uses ssh) commands fail as git cannot get the required keys (that plink provides).

Some solution ideas:

  1. Check for if the env-args GIT_SSH_COMMAND / GIT_SSH are set, and if so do not overwrite - however git has the config options core.sshCommand and ssh.variant - though not sure what version of git they were added
  2. Don't set, or make it an opt-in to set GIT_SSH_COMMAND - this way users are aware, and make an explicit choice.

IMO, the user should set this behaviour within git's config, rather than the tool - of course it helps to be aware to do it.
When trying to work out why lazy wasn't working for me, looking at the git source, the ssh_command detection / flags are a bit out-of-date, i.e. it does not specify either OpenSSH nor plink with the -BathMode=yes or -batch resepctively, but does explicit ly for tortoiseplink which I believe added -batch before plink. So perhaps the fix is really an issue for upstream git?

For other users with my somewhat esoteric setup, I set ssh.variant tortoiseplink and core.sshCommand to the plink executable within git config

Steps To Reproduce

  1. Use windows
  2. Configure Git to use plink.exe (putty) put in the env: GIT_SSH = C:\Program Files\PuTTY\plink.exe

Alternatively:

  1. Set core.sshCommand to plink executable within git config

Expected Behavior

lazy.nvim to respect the GIT_SSH or GIT_SSH_COMMAND or related config options.

Repro

-- DO NOT change the paths and don't remove the colorscheme
local root = vim.fn.fnamemodify("./.repro", ":p")

-- set stdpaths to use .repro
for _, name in ipairs({ "config", "data", "state", "cache" }) do
  vim.env[("XDG_%s_HOME"):format(name:upper())] = root .. "/" .. name
end

-- bootstrap lazy
local lazypath = root .. "/plugins/lazy.nvim"
if not vim.loop.fs_stat(lazypath) then
  vim.fn.system({ "git", "clone", "--filter=blob:none", "https://github.com/folke/lazy.nvim.git", lazypath, })
end
vim.opt.runtimepath:prepend(lazypath)

-- install plugins
local plugins = {
  "folke/tokyonight.nvim",
  -- add any other plugins here
}
require("lazy").setup(plugins, {
  root = root .. "/plugins",
})

vim.cmd.colorscheme("tokyonight")
-- add anything else here
@ixil ixil added the bug Something isn't working label Feb 5, 2023
@folke folke closed this as completed in 452d4eb Feb 6, 2023
@folke
Copy link
Owner

folke commented Feb 6, 2023

I don't want to remove the GIT_SSH_COMMAND by default. It would make updating/installing/checking for updates way slower.

Just pushed a change where you can override GIT_SSH_COMMAND.

Just set it like vim.env.GIT_SSH_COMMAND = " " or though other means

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants