No signcolumn refresh after nvim fixendofline adds newline

[neilord]

Description

After a newline is added by the fixendofline (new)vim option triggered by saving the file, gitsigns does not update the signcolumn to indicate that change. Only after reopening the file, gitsigns highlight the change on the last line.

Neovim version

NVIM v0.10.0-dev-3097+g064f3e42e

Operating system and version

macOS 14

Expected behavior

Gitsigns does refresh signcolumn after fixendofline adds newline.

Actual behavior

Gitsigns does NOT refresh signcolumn after fixendofline adds newline.
Also, the Gitsigns refresh and even Gitsigns detach + Gitsigns attach do not refresh the signcolumn.

Minimal config

for name, url in pairs{
  gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
} do
  local install_path = vim.fn.fnamemodify('gitsigns_issue/'..name, ':p')
  if vim.fn.isdirectory(install_path) == 0 then
    vim.fn.system { 'git', 'clone', '--depth=1', url, install_path }
  end
  vim.opt.runtimepath:append(install_path)
end

require('gitsigns').setup{
  debug_mode = true, -- You must add this to enable debug messages
}

vim.opt.fixendofline = true
vim.opt.signcolumn = "yes"

Steps to reproduce

1. Create empty repo: $ cd && mkdir gitsigns_test && cd gitsigns_test && git init
2. Create file with no newline in the end: $ echo -n 'test' > file
3. Commit changes: $ git add . && git commit -m 'commit'
4. Open file with nvim $ nvim --clean -u minimal_lua_path file
5. Run :w in nvim and see that despite neovim adding newline (because of the fixendofline setting), gitsigns do not show any difference in the signcolumn.
6. Reopen the file (repeat step 4) to see the signcolumn updated.

Gitsigns debug messages

No response

[lewis6991]

I found a small bug which I fixed in c96e3cf but that shouldn't be related.

Otherwise, it seems to work for me.

Can you double check using minimal.lua?

[neilord]

@lewis6991, thanks!
Have double checked it with minimal.lua, still not working (see 30 sec below):

file.mov

[lewis6991]

What you are showing in the video is different from the reproductions steps. If the file is committed without an EOF char, then gitsigns should not show a diff upon opening the file.

Can you please update the reproduction steps with exact commands.

Vscode is not relevant here. You can create a file without EOF using:

echo -n 'hello\n'world' > file
git add file
git commit

Also double check if you have a .editorconfig file.

[neilord]

@lewis6991 Got it, thanks! I have updated the Steps to reproduce section in this issue.

[lewis6991]

Works fine for me.

Screen.Recording.2024-05-28.at.13.54.08.mov

[neilord]

@lewis6991, interesting, thanks a lot for taking your time on this one! Will investigate deeper into my setup.

[lewis6991]

Any updates? Is this still an issue?

[neilord]

Any updates? Is this still an issue?

Unfortunately, it is still not working for me as described in the "Steps to reproduce" with minimal.lua
Through if it is working on your machine maybe it is my issue.

[joshuarubin]

I still have this issue too. Also macOS. I had fixed it previously with adding vim.api.nvim_set_option_value("eol", false, { buf = bufnr }) to opts.on_attach passed to setup(opts). That fix no longer works. gitsigns stages files with an extra trailing newline. I'll delete that newline from the stage side, but it is still added despite not existing in the source buffer. The source buffer then shows the modification in the signcolumn on the last line after staging any file.

[lewis6991]

I'm struggling to reproduce this issue. Can someone provide this in form of a script I can run (no written steps)?

[joshuarubin]

I was able to reproduce the same issue with neogit diff (using diffview) as well. This is very weird. What platform are you testing on? I wonder if it is a git config setting somehow.

[lewis6991]

Any config can be localised to a test case.

[joshuarubin]

still having an issue with this on a minimal config (only lazy and gitsigns):

init.lua:

vim.g.mapleader = ","
vim.g.maplocalleader = ","

local lazypath = vim.fn.stdpath("data") .. "/lazymin/lazy.nvim"
if not (vim.uv or vim.loop).fs_stat(lazypath) then
    local lazyrepo = "https://github.com/folke/lazy.nvim.git"
    local out = vim.fn.system({ "git", "clone", "--filter=blob:none", "--branch=stable", lazyrepo, lazypath })
    if vim.v.shell_error ~= 0 then
        vim.api.nvim_echo({
            { "Failed to clone lazy.nvim:\n", "ErrorMsg" },
            { out, "WarningMsg" },
            { "\nPress any key to exit..." },
        }, true, {})
        vim.fn.getchar()
        os.exit(1)
    end
end

vim.opt.rtp:prepend(lazypath)

require("lazy").setup({
    root = vim.fn.stdpath("data") .. "/lazymin", -- directory where plugins will be installed
    spec = {
        { import = "min" },
    },
    install = { colorscheme = { "habamax" } },
    checker = { enabled = true },
})

lua/min/init.lua

return {
    {
        "lewis6991/gitsigns.nvim",
        dependencies = {
            "nvim-lua/plenary.nvim",
        },
        opts = {
            on_attach = function(bufnr)
                local gs = package.loaded.gitsigns
                vim.keymap.set("n", "<leader>gd", gs.diffthis, { buffer = bufnr, desc = "diff this" })
                -- vim.api.nvim_set_option_value("eol", false, { buf = bufnr })
            end,
        },
    },
}

[lewis6991]

Why is plenary in there?

There's also no steps to follow.

[joshuarubin]

Apologies for the delay, I had some travel. I thought plenary was a required dependency. I've removed it with the same result.

Reproduction steps with that config are:

1. open a git managed file
2. make and save any change to that file
3. open diffview (as in keymap above)
4. stage any change
5. save the staged change
6. the staged file now has an extra newline appended that the source file does not have

[lewis6991]

Thanks but ideally I'd like this in form of an automated script (as requested here), and ideally without diffview.nvim.

If I can easily reproduce it, then I can invest the time to fix it. Otherwise, like many other bugs, these issues can quickly become a time sink. More than a few times, issues like these end up being a problem on the users side.