[mini.git] minigit_summary.head_name on a new file

[ndavd]

Contributing guidelines

• [X] I have read CONTRIBUTING.md
• [X] I have read CODE_OF_CONDUCT.md
• [X] I have updated 'mini.nvim' to latest version

Module(s)

mini.git

Description

This is my current config for mini.git:

  git = function()
    -- Set the summary string to just the branch
    local format_summary_string = function(data)
      local summary = vim.b[data.buf].minigit_summary
      vim.b[data.buf].minigit_summary_string = summary and summary.head_name
        or ''
    end
    vim.api.nvim_create_autocmd(
      'User',
      { pattern = 'MiniGitUpdated', callback = format_summary_string }
    )

    return {
      command = {
        split = 'vertical',
      },
    }
  end,

I'm setting the summary_string to the branch name so that I can set it on my stl. When creating a new file the minigit_summary is nil, and after saving it and switch between buffers eventually also get some seemingly random (??) after the branch name.

My goal is to have it always show the branch name when a file gets created inside a repository. Similar to what vim.fn.FugitiveHead(8) does.

Neovim version

NVIM v0.11.0-dev-136+g5c3381544

[echasnovski]

Thanks for the issue!

Yes, I can reproduce. The issue seems to be that MiniGitUpdated can be triggered with the wrong buffer identifier in the event data itself. Providing buffer identifier in the data.data.buf and using it in that autocommand seems to solve this issue.

I'll work on it.

---

... also get some seemingly random (??) after the branch name.

The (??) is a git status of a new (i.e. not tracked and not ignored) file. It is a default format of minigit_summary_string.

[echasnovski]

This should be fixed on latest main. No adjustment needed for how minigit_summary_string tweaking is done, as MiniGitUpdated User event should now be triggered with target buffer being current. Technically, even using data.buf for vim.b is not needed, but I think it is a safer option to keep using it.

Thanks for finding this!

[ndavd]

Thank you!! Can confirm that it no longer shows (??) after creating a new file and switching between buffers. However, it still shows nil until I save a new file, for example if I do :e my-new-file it still shows nil until I save it.

[echasnovski]

However, it still shows nil until I save a new file, for example if I do :e my-new-file it still shows nil until I save it.

It is expected, because executing :e my-new-file does not create actual file on disk, which is needed for Git to know about it.

Edit: executing :write after creating buffer for the new file also does not immediately update 'mini.git' tracking information, because no tracking is done in that buffer. Follow up with either :edit (to "restart" buffer tracking) or go outside/inside buffer. I think this is a rare and mild enough inconvenience to be left as is.

[ndavd]

It is expected, because executing :e my-new-file does not create actual file on disk, which is needed for Git to know about it.

Edit: executing :write after creating buffer for the new file also does not immediately update 'mini.git' tracking information, because no tracking is done in that buffer. Follow up with either :edit (to "restart" buffer tracking) or go outside/inside buffer. I think this is a rare and mild enough inconvenience to be left as is.

Do you have any solution for that in mind that I could perhaps apply to my config? If not I'll leave it as is

[echasnovski]

Do you have any solution for that in mind that I could perhaps apply to my config? If not I'll leave it as is

I am not sure what solution you'd expect here. 'mini.git' tracks and will continue to track only buffers corresponding to an actual files on disk. So expect to only have Git information in statusline for such buffers.

To avoid situations like immediately after :edit my-new-file:

• Create file beforehand (like inside 'mini.files', with :!touch my-new-file, or other tools) and then it with :edit my-new-file.
• Call :edit without arguments or reenter the buffer after :edit my-new-file - :write.