bug: Invalid lockfile generated when at least one plugin is cloned with Git's new reftable refs format

[sid-maddy]

Did you check docs and existing issues?

• I have read all the lazy.nvim docs
• I have updated the plugin to the latest version before submitting this issue
• I have searched the existing issues of lazy.nvim
• 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

lazy.nvim/lua/lazy/manage/lock.lua

Line 29 in 6c3bda4

commit = assert(info.commit, "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

lazy.nvim/lua/lazy/manage/task/git.lua

Line 90 in 6c3bda4

error(k .. " '" .. v .. "' not found")

Workaround

Manually switch the refs format of the cloned plugin from reftable to the files format.

1. Navigate to the directory where the plugin is cloned.
2. Run

git fetch
git refs migrate --ref-format=files

Steps To Reproduce

1. Update git to v2.51.0 or greater
2. Add a new plugin to the config
3. 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,
		},
	},
})

[dpetka2001]

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.

[sid-maddy]

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.

[kapral18]

turns out you can keep feature.experimental=true and just override init.defaultRefFormat=files in your git config and everything works

[github-actions]

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.

[ahmedelgabri]

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