Signs don't go away after hunk is staged

minhduc0711 commented 2 months ago

Description

When I stage a hunk, the corresponding diff sign no longer disappear.

Neovim version

NVIM v0.10.0

Operating system and version

Ubuntu 22.04.4 LTS

Expected behavior

The sign should disappear after staging a hunk.

Actual behavior

The sign is still there after staging the hunk, with the weird "Hunk 1 of 0" message.

Minimal config

for name, url in pairs{
  gitsigns = 'https://github.com/lewis6991/gitsigns.nvim',
  -- ADD OTHER PLUGINS _NECESSARY_ TO REPRODUCE THE ISSUE
} 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
}

Steps to reproduce

git clone https://github.com/octocat/Hello-World && cd Hello-World
Add a line of text in README.
Gitsigns stage_hunk on the added line.
Gitsigns preview_hunk on the hunk that is still there.

Gitsigns debug messages

0.79 D dprintf: Deriving GitSignsAdd from Added
0.83 D derive: Deriving GitSignsChange from Changed
0.97 D derive: Deriving GitSignsDelete from Removed
0.99 D derive: Deriving GitSignsChangedelete from GitSignsChange
1.03 D derive: Deriving GitSignsTopdelete from GitSignsDelete
1.06 D derive: Deriving GitSignsUntracked from GitSignsAdd
1.10 D derive: Deriving GitSignsAddNr from GitSignsAdd
1.12 D derive: Deriving GitSignsChangeNr from GitSignsChange
1.18 D derive: Deriving GitSignsDeleteNr from GitSignsDelete
1.20 D derive: Deriving GitSignsChangedeleteNr from GitSignsChangeNr
1.23 D derive: Deriving GitSignsTopdeleteNr from GitSignsDeleteNr
1.27 D derive: Deriving GitSignsUntrackedNr from GitSignsAddNr
1.31 D derive: Deriving GitSignsAddLn from DiffAdd
1.34 D derive: Deriving GitSignsChangeLn from DiffChange
1.38 D derive: Deriving GitSignsChangedeleteLn from GitSignsChangeLn
1.40 D derive: Deriving GitSignsUntrackedLn from GitSignsAddLn
1.42 D derive: Deriving GitSignsStagedAdd from GitSignsAdd
1.45 D derive: Deriving GitSignsStagedChange from GitSignsChange
1.47 D derive: Deriving GitSignsStagedDelete from GitSignsDelete
1.49 D derive: Deriving GitSignsStagedChangedelete from GitSignsChangedelete
1.51 D derive: Deriving GitSignsStagedTopdelete from GitSignsTopdelete
1.54 D derive: Deriving GitSignsStagedAddNr from GitSignsAddNr

lewis6991 commented 2 months ago

You probably don't have termguicolors set.

GitSignsStagedAdd is linked to GitSignsAdd, so they will appear the same.

eshepelyuk commented 2 months ago

Hello, after this commit de18f6b749f6129eb9042a2038590872df4c94a9 - I have similar issues

I have termguicolors set. When I stage a hunk it becomes less bright, but the issue is that when I start navigating hunks (using keymap from README), the plugin goes crazy in different ways, e.g.

plugin navigates to already staged hunks ( why it should not )
plugin starts to show already staged hunks with unstaged HL
hunk counter in the bottom starts showing crazy numbers, like 1 of 10 ( while I only have 2-3 changes)
then it starts showing like 200 of 200
etc

There's no certain pattern, I am just opening random git file with changes, try to stage one hunk and navigate between remaining ones.

PS

nvim --version
NVIM v0.10.0
Build type: Release
LuaJIT 2.1.1716656478
Run "nvim -V1 -v" for more info

uname -a
Linux xxx-nb 5.15.153.1-microsoft-standard-WSL2 #1 SMP Fri Mar 29 23:14:13 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux

lewis6991 commented 2 months ago

@eshepelyuk Please do not overload specific issues with your own problems. Please raise separate issues with reproducible steps.

It sounds like you do not like the current behaviour of staged hunks, in which case you can disabled it with signs_staged_enable = false.

minhduc0711 commented 2 months ago

It sounds like you do not like the current behaviour of staged hunks, in which case you can disabled it with signs_staged_enable = false.

This is what I was looking for. Doesn't signs_staged_enable = false use to be the default value?

lewis6991 / gitsigns.nvim