NeogitOrg / NeogitOrg/neogit

Wrong line endings applied to staged hunk when applying hunk to repository index

Open
#2,011 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

bug
Dominant language
Lua
Stars
5.6k
Forks
357
Avg merge
15h 47m
Merged PRs (30d)
2

Description

Description

When staging a hunk, there's a chance it'll apply the hunk with the wrong line endings, causing the entire file to be considered as changed in its entirety due to it modifying the index and causing the index to change line endings.

This is a niche case that happens on presumably any repository that works with mixed line endings or where the repository is developed in one format but not the other for a different platform (Windows <> Linux, either direction probably).

I personally encountered this on Windows, where only staging hunks with additions caused this issue, not any other type of hunk. I maintain a fix on a local fork that I'll open a PR for which has a pretty heavy fix that works well to avoid this, but it's just one possible solution to it.

Neovim version

NVIM v0.12.4
Build type: Release
LuaJIT 2.1.1774638290
Run "nvim -V1 -v" for more info

Operating system and version

Windows 11 KB5124008

Steps to reproduce
  1. On Windows, on a repository committed in lf but working locally in crlf without core.autocrlf set in Git config, make a change that adds lines to the patch;
  2. Stage only the hunk, not the entire file, within Neogit's status interface;
  3. Observe that it considers the entire file to be changed, not just the hunk.
Expected behavior

It should work as it does on other platforms and when the line ending is consistently, as well as how it normally does when committing the whole file: it should only treat the changes as a change, not cause a change that causes the entire file to be considered to be different.

Actual behavior

It causes the index to change line endings entirely, causing it to cause the entire file to be considered as changed if the working file is in a different line ending and certain Git configuration options aren't set, which may be valid for some work configurations.

Minimal config
-- NOTE: See the end of this file if you are reporting an issue, etc. Ignore all the "scary" functions up top, those are
-- used for setup and other operations.
local M = {}

local base_root_path = vim.fn.fnamemodify(debug.getinfo(1, "S").source:sub(2), ":p:h") .. "/.min"
function M.root(path)
  return base_root_path .. "/" .. (path or "")
end

function M.load_plugin(plugin_name, plugin_url)
  local package_root = M.root("plugins/")
  local install_destination = package_root .. plugin_name
  vim.opt.runtimepath:append(install_destination)

  if not vim.loop.fs_stat(package_root) then
    vim.fn.mkdir(package_root, "p")
  end

  if not vim.loop.fs_stat(install_destination) then
    print(string.format("> Downloading plugin '%s' to '%s'", plugin_name, install_destination))
    vim.fn.system({
      "git",
      "clone",
      "--depth=1",
      plugin_url,
      install_destination,
    })
    if vim.v.shell_error > 0 then
      error(string.format("> Failed to clone plugin: '%s' in '%s'!", plugin_name, install_destination),
        vim.log.levels.ERROR)
    end
  end
end

---@alias PluginName string The plugin name, will be used as part of the git clone destination
---@alias PluginUrl string The git url at which a plugin is located, can be a path. See https://git-scm.com/book/en/v2/Git-on-the-Server-The-Protocols for details
---@alias MinPlugins table<PluginName, PluginUrl>

---Do the initial setup. Downloads plugins, ensures the minimal init does not pollute the filesystem by keeping
---everything self contained to the CWD of the minimal init file. Run prior to running tests, reproducing issues, etc.
---@param plugins? table<PluginName, PluginUrl>
function M.setup(plugins)
  vim.opt.packpath = {}                      -- Empty the package path so we use only the plugins specified
  vim.opt.runtimepath:append(M.root(".min")) -- Ensure the runtime detects the root min dir

  -- Install required plugins
  if plugins ~= nil then
    for plugin_name, plugin_url in pairs(plugins) do
      M.load_plugin(plugin_name, plugin_url)
    end
  end

  vim.env.XDG_CONFIG_HOME = M.root("xdg/config")
  vim.env.XDG_DATA_HOME = M.root("xdg/data")
  vim.env.XDG_STATE_HOME = M.root("xdg/state")
  vim.env.XDG_CACHE_HOME = M.root("xdg/cache")

  -- NOTE: Cleanup the xdg cache on exit so new runs of the minimal init doesn't share any previous state, e.g. shada
  vim.api.nvim_create_autocmd("VimLeave", {
    callback = function()
      vim.fn.system({
        "rm",
        "-r",
        "-f",
        M.root("xdg")
      })
    end
  })
end

-- NOTE: If you have additional plugins you need to install to reproduce your issue, include them in the plugins
-- table within the setup call below.
M.setup({
  plenary = "https://github.com/nvim-lua/plenary.nvim.git",
  telescope = "https://github.com/nvim-telescope/telescope.nvim",
  diffview = "https://github.com/sindrets/diffview.nvim",
  neogit = "https://github.com/NeogitOrg/neogit"
})
-- WARN: Do all plugin setup, test runs, reproductions, etc. AFTER calling setup with a list of plugins!
-- Basically, do all that stuff AFTER this line.
require("neogit").setup({}) -- For instance, setup Neogit

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue in Neogit's status interface using the Windows mixed-line-ending setup described in the steps. Trace the hunk-staging path and compare the index and working-file line endings; done means staging an added hunk changes only that hunk rather than the entire file.

Written by the indexing model from the issue text.

Assessment

Tech stack
git, lua, neovim
Domain
cli, devtools, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.