bug: Invalid lockfile generated when at least one plugin is cloned with Git's new reftable refs format
Did you check docs and existing issues?
- [x] I have read all the lazy.nvim docs
- [x] I have updated the plugin to the latest version before submitting this issue
- [x] I have searched the existing issues of lazy.nvim
- [x] I have searched the existing issues of plugins related to this issue
Neovim version (nvim -v)
v0.11.4
Operating system/version
macOS 15.6.1
Describe the bug
Installing a plugin with git v2.51.0 clones the plugin's repository with the new reftable refs format.
See [ANNOUNCE] Git v2.51.0 for more details.
lazy.nvim installs the plugin, but fails to fetch the logs of the plugin, and more importantly, generates an invalid lockfile (lazy-lock.json) containing only an opening brace ({)
The below error is shown after :Lazy syncing the first time:
~/.local/share/nvim/lazy/lazy.nvim/lua/lazy/manage/lock.lua:29: commit is nil
The below error is shown after closing and reopening :Lazy:
~/.local/share/nvim/lazy/lazy.nvim/lua/lazy/manage/task/git.lua:90: branch '.invalid' not found
Workaround
Manually switch the refs format of the cloned plugin from reftable to the files format.
- Navigate to the directory where the plugin is cloned.
- Run
git fetch
git refs migrate --ref-format=files
Steps To Reproduce
- Update
gittov2.51.0or greater - Add a new plugin to the config
- Sync the config (
:Lazy sync)
Expected Behavior
lazy.nvim installs the plugin, is able to fetch the logs of the plugin, and generates a valid lockfile (lazy-lock.json).
Repro
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
spec = {
{
"Shatur/neovim-ayu",
opts = {},
config = function(_, opts)
local ayu = require("ayu")
ayu.setup(opts)
ayu.colorscheme()
end,
},
},
})
This setting is not default yet. It will be made default on version 3.0 according to the link you provided.
I use git 2.51 and don't face this problem. In the link you provided, it mentions that this setting will be enabled only when feature.experimental is enabled in your git config.
Not to say that this won't be a problem when git 3.0 will get released, but it hasn't been released yet and the problem you face is due to an experimental feature that you don't know if that will be its final form when git 3.0 will get released.
I checked and forgot I had feature.experimental set to true in my global config.
Setting it to false makes the repro config work as expected.
Keeping the issue open, since it might still be a problem once git 3.0 releases.
turns out you can keep feature.experimental=true and just override init.defaultRefFormat=files in your git config and everything works
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.
~~I'm on 2.51.0 and don't have feature.experimental set to true and I have the same problem. I also tried~~
git fetch
git refs migrate --ref-format=files
~~And what I get back is error: repository already uses 'files' format~~
Ignore, it seems that something is not right with GH related to https://github.com/devkvlt/go-tags.nvim