Beta-testing 'mini.git'

[echasnovski]

Please leave your feedback about new mini.git module here. Feel free to either add new comment or positively upvote existing one.

Some things I am interested to find out (obviously, besides bugs):

• Does it track smoothly the git-related data (i.e. at least no visible errors reported).
• Does :Git command have proper completions and intuitive split behavior?
• Is configuration intuitive enough?
• Are default values of settings convenient for you?
• Is documentation and examples clear enough?

Thanks!

[clason]

Can we support :Git commit -m "foo bar"?

[echasnovski]

Can we support :Git -m "foo bar"?

What is it supposed to do? As :Git commit -m "foo bar"? If yes, then I don't think it is worthwhile to add this special behavior.

[clason]

Yes, sorry. It should behave exactly like git commit -m "foo bar". (After all, "if it works with git, it should work with :Git"...)

[echasnovski]

After all, "if it works with git, it should work with :Git"...

This is indeed the goal. But git -m "foo bar" does not work for me from CLI. It says unknown option: -m. And :Git behaves the same.

Can we support :Git commit -m "foo bar"?

Yes, of course this works. With slight caveat: :Git commit -m foo\ bar.

[clason]

Yes. I am explicitly referring to that; I would prefer not to need a special syntax.

[echasnovski]

Yes. I am explicitly referring to that; I would prefer not to need a special syntax.

Ah, I see now. No, I don't think it will be added, as the current approach feels more like how Vim user commands work.

[clason]

Ok. Then I'll just leave two more suggestions here for the record; no need to respond:

• I would suggest making the fugitive behavior (split + scrollbind) the default for Git blame
• Consider mapping show_at_cursor for mini.git buffers, e.g., to K.

[echasnovski]

Ok. Then I'll just leave two more suggestions here for the record; no need to respond:

Thanks!

In case other people miss it in help file.

* I would suggest making the fugitive behavior (split + `scrollbind`) the default for `Git blame`

There is an example of customizing blame subcommand (preferably be used inside mapping with <Cmd>vert Git blame -- %<CR> right hand side).

* Consider mapping `show_at_cursor` for `mini.git` buffers, e.g., to `K`.

I'd suggest mapping it some <Leader> mapping as it can be used inside regular Git-tracked file to show range history. But making buffer-local mapping is also possible (albeit a bit verbose for the most robust behavior):

local map_local = vim.schedule_wrap(function(data)
  if not vim.api.nvim_buf_is_valid(data.buf) then return end
  local buf_name = vim.api.nvim_buf_get_name(data.buf)
  if not vim.startswith(buf_name, 'minigit://') then return end
  vim.keymap.set({ 'n', 'x' }, 'K', MiniGit.show_at_cursor, { buffer = data.buf })
end)
-- Alternative is to map for `User` `MiniGitCommandSplit` event, but
-- it would not trigger when buffer is created with `show_xxx()` functions
vim.api.nvim_create_autocmd('BufNew', { callback = map_local })

[231tr0n]

Is there a way where i can navigate through diff changes in all the files(not just current buffer) like I can using :Git command in vim-fugitive. Also stage and unstage hunks like I can in vim-fugitive.

[echasnovski]

The 'mini.git' module is not meant as a full Git client, so do not expect full feature parity with 'vim-fugitive'. Here is a comparison to 'vim-fugitive'.

Is there a way where i can navigate through diff changes in all the files(not just current buffer) like I can using :Git command in vim-fugitive.

Not like in 'vim-fugitive', but you can use plain :Git diff with enabled folding. Ideally, you'd be able to navigate to diff source with show_at_cursor(), but show_diff_source() (and hence show_at_cursor()) does not work in that output (needs explicit commit). I'll look at how it can resolved.

Also stage and unstage hunks like I can in vim-fugitive.

The suggested way is to use 'mini.diff' for staging hunks when inside a buffer. Interactive unstaging is not supported, only with what git CLI through :Git can offer.

[rafamadriz]

@echasnovski Thanks for your amazing work. This fits really nice within my workflow since I don't need the full feature set of fugitive (for that I use lazygit).

I just have one question so asking here to not create an issue, what's the purpose of setting foldlevel ?

https://github.com/echasnovski/mini.nvim/blob/e94945129780fa5b43447ecc0a4b0273892043e3/lua/mini/git.lua#L1120

I have a modified commit message that shows for commits, and I use folds for some parts which I'd rather start closed, for that I have vim.opt.foldlevel = 0 in after/ftplugin/gitcommit.lua. It works fine when doing it from the command line git commit but if I do it inside neovim (:Git commit) then foldlevel is set to 999. So really my question is, is there anyway that options in after/ftplugin/gitcommit.lua are not overwritten ?

[echasnovski]

I just have one question so asking here to not create an issue, what's the purpose of setting foldlevel ?

I am using foldmethod=indent (and recommending it to everyone). So output of :Git command in split tended to be folded when I did not expect it to (like after :Git help commit). As that foldlevel is set before manually setting filetype in output of :Git command, it works in most cases. It just doesn't work in GIT_EDITOR (like for commit). I'll fix this (probably tomorrow), as setting vim.wo.foldlevel = 0 in 'after/ftplugin/gitcommit.lua' should work.

[tssm]

Hey @echasnovski, this is great! It covers most of what I wanted from Fugitive without its complexity, and for the rest I can create my own mappings :)

Regarding the split behavior, I miss an option to use the current window by default, without touching the tab layout at all, and without creating a new tab

[echasnovski]

Hey @echasnovski, this is great! It covers most of what I wanted from Fugitive without its complexity, and for the rest I can create my own mappings :)

That's great to hear!

Regarding the split behavior, I miss an option to use the current window, without touching the tab layout at all, and without creating a new tab

Yeah, I've thought about this one. In early prototypes it even preferred reusing window if it already showed a buffer from 'mini.git'.

There are two main reasons (aside from a convenient for implementation "there is always a new window" invariant) for not including something like split = 'none':

• The buffers from 'mini.git' are cleaned up after window is closed. If not done, they will be accumulating in buffer list, which is not nice. The usual approach of setting buftype=wipeout so that buffer is wiped out when it is not visible is not great here, because it prevents exploring other buffers in the same window.
• There is no good user command modifier to force it. Unlike "horizontal", "vertical", and "tab". So having only one not enforceable split direction ("auto") felt more appropriate.

I'll have this mind, but not sure if this is a good idea. I do wonder about supporting split = 'float' for floating windows, but that would require exposing a config.window.config option, which is also not great. Maybe some time later.

[tssm]

The usual approach of setting buftype=wipeout so that buffer is wiped out when it is not visible is not great here, because it prevents exploring other buffers in the same window.

What do you mean here? I ask because for all Git related buffers I do set bufhidden to wipe, and I wonder what workflow I'm breaking here.

Anyway, it shouldn't be hard for me to make it work as I want it. I think for now I'll set split to vertical and leverage the MiniGitCommandSplit event to close the previous window, and who knows, maybe after a while I want the auto behaviour back

[echasnovski]

What do you mean here? I ask because for all Git related buffers I do set bufhidden to wipe, and I wonder what workflow I'm breaking here.

If you run something like :Git log and then want to take a quick look of previous buffer to double check something (with [b, for example), the 'git' buffer is wiped out now (and you have to redo :Git log).

[tssm]

Right, that's the behavior I expect, as I think all those buffers are temporary anyway. It's a bit annoying when Git log is closed by mistake, granted, but I feel the issue there is that it takes a while to generate. I wonder if it could be sped up somehow. For now, I'm used to always run Git log main..

Unrelated, I just noticed not all buffers have a setlocal nomodifiable set. Is this intended? I'm unconditionally setting it now on my MiniGitCommandSplit autocommand

[echasnovski]

Unrelated, I just noticed not all buffers have a setlocal nomodifiable set. Is this intended? I'm unconditionally setting it now on my MiniGitCommandSplit autocommand

Not intentional intentional, but I don't really see a problem with them being modifiable. Maybe users want to modify before copying or something.

[pkazmier]

Congratulations on the new module! I quickly set it this morning before I headed to the office. Two quick questions / comments:

1. Took me longer than it should have after reading the docs to figure out that I did not have to explicitly call enable(). Maybe I missed it, but no where did I find it say this is enabled by default. I think the part that confused me is the first bullet item of features refers one to the enable function, which I took to imply I needed to explicitly enable this somehow.
2. Not really a mini.git question, but is there a way to lock two windows together so they are synchronized when moving up/down? Use case would be for the blame windows opens vertically.

Thanks again! Love the ability to use show_at_cursor to interactively explore. So simple and clever.

[echasnovski]

1. Took me longer than it should have after reading the docs to figure out that I did not have to explicitly call enable(). Maybe I missed it, but no where did I find it say this is enabled by default. I think the part that confused me is the first bullet item of features refers one to the enable function, which I took to imply I needed to explicitly enable this somehow.

Hmm... Yeah, I see how this might be confusing. This is documented in setup() (as it is the one that actually sets up autoenabling).

Would adding here a line "Note: this function is called automatically for all new normal buffers. Use it explicitly if buffer was disabled." have helped?

2. Not really a mini.git question, but is there a way to lock two windows together so they are synchronized when moving up/down? Use case would be for the blame windows opens vertically.

Yes, it can be done with 'scrollbind' option. Here is the example of how to customize :Git blame to do just that.

Thanks again! Love the ability to use show_at_cursor to interactively explore. So simple and clever.

Thanks! It indeed felt quite intuitive for me once I had started using it.

[pkazmier]

Hmm... Yeah, I see how this might be confusing. This is documented in setup() (as it is the one that actually sets up autoenabling). Would adding here a line "Note: this function is called automatically for all new normal buffers. Use it explicitly if buffer was disabled." have helped?

Yes, that would have been helpful. I simply missed it in the setup docs as with the blame example as I was rushing this morning before work to set this up. My apologies, I really don't list wasting your time with things already written down!

[rchhong]

I'm using lazy package manager and I get the following error installing this plugin using the recommended install method. I'm guessing that it might have something to do with the naming, as this plugin is the only one that uses a hypen instead of a dot. I'm using nvim 0.10.0 with lazy version 10.20.5 on a MacOS 14.4.1 if that helps.

Failed to run `config` for mini-git

...local/share/nvim/lazy/lazy.nvim/lua/lazy/core/loader.lua:373: module 'mini' not found:
^Ino field package.preload['mini']
cache_loader: module mini not found
cache_loader_lib: module mini not found
^Ino file './mini.lua'
^Ino file '/opt/homebrew/share/luajit-2.1/mini.lua'
^Ino file '/usr/local/share/lua/5.1/mini.lua'
^Ino file '/usr/local/share/lua/5.1/mini/init.lua'
^Ino file '/opt/homebrew/share/lua/5.1/mini.lua'
^Ino file '/opt/homebrew/share/lua/5.1/mini/init.lua'
^Ino file '/Users/ryanchhong/.luarocks/share/lua/5.1/mini/init.lua'
^Ino file '/Users/ryanchhong/.luarocks/share/lua/5.1/mini.lua'
^Ino file './mini.so'
^Ino file '/usr/local/lib/lua/5.1/mini.so'
^Ino file '/opt/homebrew/lib/lua/5.1/mini.so'
^Ino file '/usr/local/lib/lua/5.1/loadall.so'

# stacktrace:
  - vim/_editor.lua:0 _in_ **cmd**
  - /persistence.nvim/lua/persistence/init.lua:87 _in_ **load**
  - ~/.config/nvim/lua/plugins/ui/dashboard.lua:32 _in_ **action**
  - /dashboard-nvim/lua/dashboard/theme/doom.lua:29

[echasnovski]

I'm using lazy package manager and I get the following error installing this plugin using the recommended install method. I'm guessing that it might have something to do with the naming, as this plugin is the only one that uses a hypen instead of a dot. I'm using nvim 0.10.0 with lazy version 10.20.5 on a MacOS 14.4.1 if that helps.

All installation instructions assume manual call require('mini.xxx').setup(). Here 'lazy.nvim' seems to be doing that automatically.

Here is the example of using 'mini.git' from standalone repository posted by Folke:

{
  "echasnovski/mini-git",
  opts = {},
  main = "mini.git",
}

I presume it should work.

[rchhong]

Ah I wasn't aware of that "main" option in lazy. I had everything else except that. I added that in and it works, but might want to add that to the mini.git installation instructions.

[ElectronSutra]

The new module looks great.

Is it in-scope for either mini.git or mini.files or mini.extra to add (a mini.files prefix?) (another method?) to show the Git status of the files?

[tssm]

How should I interpret win_source provided by MiniGitCommandSplit? I expected it to be the window number, but on a fresh instance, with just one window, after a command splits it, the value is always 1000 instead of 1

[echasnovski]

Is it in-scope for either mini.git or mini.files or mini.extra to add (a mini.files prefix?) (another method?) to show the Git status of the files?

@ElectronSutra, probably yes. As part of 'mini.extra'.

How should I interpret win_source provided by MiniGitCommandSplit? I expected it to be the window number, but on a fresh instance, with just one window, after a command splits it, the value is always 1000 instead of 1

It is a window identifier, as documented. See :h window-ID.

[echasnovski]

I've pushed several updates.

---

@rafamadriz, using setlocal foldlevel=0 in 'after/ftplugin/gitcommit.lua' should now work.

---

@pkazmier, I added note about autoenabling in enable() help. Hope it will be clearer for future users.

---

@rchhong, installation instructions for 'lazy.nvim' now have main field.

[konosubakonoakua]

error with nvim-ufo after executing :Git log --oneline

Error executing vim.schedule lua callback: UnhandledPromiseRejection with the reason:
...local/share/nvim/lazy/nvim-ufo/lua/ufo/provider/init.lua:36: attempt to call upvalue 'mainFunc' (a nil value)

[echasnovski]

error with nvim-ufo after executing :Git log --oneline

Error executing vim.schedule lua callback: UnhandledPromiseRejection with the reason:
...local/share/nvim/lazy/nvim-ufo/lua/ufo/provider/init.lua:36: attempt to call upvalue 'mainFunc' (a nil value)

I can not reproduce after installing and enabling 'kevinhwang91/nvim-ufo' with the following code:

add('kevinhwang91/promise-async')
add('kevinhwang91/nvim-ufo')
vim.o.foldcolumn = '1'
vim.o.foldlevel = 99
vim.o.foldlevelstart = 99
vim.o.foldenable = true
require('ufo').setup()

[konosubakonoakua]

error with nvim-ufo after executing :Git log --oneline

Error executing vim.schedule lua callback: UnhandledPromiseRejection with the reason:
...local/share/nvim/lazy/nvim-ufo/lua/ufo/provider/init.lua:36: attempt to call upvalue 'mainFunc' (a nil value)

I can not reproduce after installing and enabling 'kevinhwang91/nvim-ufo' with the following code:

add('kevinhwang91/promise-async')
add('kevinhwang91/nvim-ufo')
vim.o.foldcolumn = '1'
vim.o.foldlevel = 99
vim.o.foldlevelstart = 99
vim.o.foldenable = true
require('ufo').setup()

My mistake, I set ftMap = {git={}}, it's empty. After set git = {"indent"}, problem solved. Thankyou.

[tssm]

Thanks for all your help @echasnovski! As I've been using it these days as my main Git client, I found a couple of features missing that hopefully are still in scope:

1. Git reflog (as Git log)
2. Git stash list (same. This is not supported by Fugitive, but I think it should)

I also miss being able to use commands with the --patch option

[echasnovski]

Thanks for all your help @echasnovski! As I've been using it these days as my main Git client, I found a couple of features missing that hopefully are still in scope:

1. Git reflog (as Git log)
2. Git stash list (same. This is not supported by Fugitive, but I think it should)

Could you elaborate on what what do you mean by "same as Git log"? My guess would be that you expect it to be shown in a split with highlighting.

Which subcommands show its output in a split is deligated to Git itself. It can provide a list of such subcommanda, which is used here.

To force any command's output to be shown in a split, explicitly use splitting command modifier: horizontal, vertical, or tab (each possibly abbreviated). If you want to automate things, there is a MiniGitCommandDone User event.

I also miss being able to use commands with the --patch option

I am not sure about what exactly is missing.

[tssm]

My guess would be that you expect it to be shown in a split with highlighting.

Yeah, that's what I meant, however using :vertical is god for now.

Which subcommands show its output in a split is deligated to Git itself. It can provide a list of such subcommanda, which is used here.

Interesting! How can I see that list?

Regarding the --patch option, if I run Git stage -p the interactive output is echoed, so I cannot interact with it. As a workaround I'm using :te git stage -p, but sometimes I forget

[echasnovski]

Interesting! How can I see that list?

git --list-cmds=list-info,list-ancillaryinterrogators,list-plumbinginterrogators

This provides the most complete list I could find.

Regarding the --patch option, if I run Git stage -p the interactive output is echoed, so I cannot interact with it. As a workaround I'm using :te git stage -p, but sometimes I forget

Interesting. I'll take a look, but no promises.

[echasnovski]

Is there a way where i can navigate through diff changes in all the files(not just current buffer) like I can using :Git command in vim-fugitive. Also stage and unstage hunks like I can in vim-fugitive.

@231tr0n, I've just pushed an update for show_diff_source() (and hence the show_at_cursor()) to work in output of some basic :Git diff commands.

The use case is indeed to extend interactive exploration to current state and make it a low effort alternative to :G command from 'vim-fugitive'.

[231tr0n]

Is there a way where i can navigate through diff changes in all the files(not just current buffer) like I can using :Git command in vim-fugitive. Also stage and unstage hunks like I can in vim-fugitive.

@231tr0n, I've just pushed an update for show_diff_source() (and hence the show_at_cursor()) to work in output of some basic :Git diff commands.

The use case is indeed to extend interactive exploration to current state and make it a low effort alternative to :G command from 'vim-fugitive'.

Awesome, thank you for accomodating this change. Will try it out right now. Your plugins are the best :)

[aikow]

Hey @echasnovski! First off, thanks for your awesome plugins.

I've noticed that getting option completions doesn't work when MANPAGER is set in the environment. In other words, mini-git reports a subprocess time-out error, and neovim is not responsive while it tries to generate completions. I currently have `MANPAGER='nvim +Man!'.

It should be possible to remove that environment variable, or set it to whatever the expected value is, from a copy of the env, and pass that to the vim.loop.spawn command in H.cli_run. Removing it completely, by setting vim.env.MANPAGER = nil, or starting nvim with MANPAGER= nvim, does fix the timeout issue, but doesn't show any actual completions. I got the same result using MANPAGER=cat

[aikow]

I also just noticed that completion for nested subcommands, like git remote get-url also don't work. I.e. when typing git remo, I get suggestions for all git remote subcommands, like

remote
remote rm
remote add
remote show
...

But as I soon as I type the space, I no longer get any suggested completions, nor do I get any completions for possible remotes, although that probably has to do with the completion failing for the nested subcommand.

[echasnovski]

I've noticed that getting option completions doesn't work when MANPAGER is set in the environment. In other words, mini-git reports a subprocess time-out error, and neovim is not responsive while it tries to generate completions. I currently have MANPAGER='nvim +Man!'.

I don't use Neovim for man pages, so currently trying to reproduce this and can not. Even with echo $MANPAGER showing nvim +Man! I still can not get man git to show inside Neovim while completion works as expected (without hanging).

I believe the reason is due to using git help --man <command> to manually parse manual pages for possible options. I am currently looking at what config value should I set for that particular command (so like adding 'c', '...' arguments) to make it return help page in a basic stdout.

But as I soon as I type the space, I no longer get any suggested completions, nor do I get any completions for possible remotes, although that probably has to do with the completion failing for the nested subcommand.

This is expected and (somewhat) documented.

The reason is that in the case of completion for :Git remote | (i.e. after a space) there is no reliable way to tell if the user wants second word as completion candidates or command's targets. Thus for all commands it suggests target while still suggesting second word if cursor is as right as at the end of the command (i.e. :Git remote|).

The reason it doesn't provide completion candidates is because remote is not included in a list of "some common subcommands" that provide target completion. You can see all such commands here as non-commented table keys. I can probably add remote there too. Are there any other commands that you feel like using frequently but not on that list?

[echasnovski]

@aikow, as I still can not reproduce the pager issue, would you mind checking if the following fixes it for you?

Find your 'mini.nvim' / 'mini.git' installation and replace this line with this one:

  local command = { MiniGit.config.job.git_executable, '--no-pager', unpack(args) }

[aikow]

@echasnovski

You can see all such commands here as non-commented table keys. I can probably add remote there too. Are there any other commands that you feel like using frequently but not on that list?

Thanks for the pointer, that helps explain the current completion behavior, and why it's often times better than fugutive. Occasionally, I find myself using git switch -d origin/branch to checkout a remote branch directly into a detached state, so that might be an argument for adding --remotes to the git switch completions. However, I was often times quite annoyed by the extra origin/... options that fugitive suggests when doing git switch, and the remote branches only make sense when the -d flag is specified, which is outside the bounds of this plugin xD.

This is expected and (somewhat) documented.

I read that, but didn't think enough to realize what exactly it would mean for certain completions. However, I don't really have any improvement suggestions, besides maybe just listing an example (although I understand if that is too granular).

Find your 'mini.nvim' / 'mini.git' installation and replace this line with this one:

I tried replacing the line, but that didn't fix it.

However, I was able to find out that git help produces fancy output, where section titles are rendered like this N\bNA\bAM\bME\bE when I examine the lines returned by the git_cli_output helper. Running git --no-pager help --man switch still tries to use MANPAGER for some reason, but explicitly setting that to cat with MANPAGER=cat git --no-pager help --man switch seems to work as expected from the terminal (outside of neovim).

local stdout = vim
  .system({ "git", "--no-pager", "help", "--man", "switch" }, {
    env = { MANPAGER = "cat" },
  })
  :wait().stdout
print(vim.inspect(vim.split(stdout, "\n")))

[aikow]

I think the --no-pager is related to things like git diff or git show, but it looks like git help uses MANPAGER and does not respect git's actual pager setting, which is probably a good thing, since I have git delta configured as my git pager, and I don't think it is any good at showing man pages 😂.

[aikow]

I just tried it on a linux machine (I was previously using mac, and it seems to work fine there.

[echasnovski]

Sigh... OK, lets then try a more nuclear approach. Could test on Mac (where there was an issue) if replacing these two lines with the following fixes the issue:

  local command = { MiniGit.config.job.git_executable, '--no-pager', unpack(args) }
  local custom_env = { NO_COLOR = 1, PAGER = 'cat', MANPAGER = 'cat' }
  local environ = vim.tbl_deep_extend('force', vim.loop.os_environ(), custom_env)
  local env = {}
  for k, v in pairs(environ) do
    table.insert(env, string.format('%s=%s', k, tostring(v)))
  end
  local res = H.cli_run(command, cwd, nil, { env = env }).out

[aikow]

That didn't work either. I also tried using less -r, less -R, and gcat as pages, none of which worked, I'm still getting output's with weird escapes. I also tried passing some git config flags directly, like color.ui=false, or man.viewer, but that didn't work either.

       g\bgi\bit\bt-\b-c\bch\bhe\bec\bck\bko\bou\but\bt(1), g\bgi\bit\bt-\b-b\bbr\bra\ban\bnc\bch\bh(1)

At this point, it might be interesting to figure out whether anyone else on MacOS has a similar issue, or whether I somehow managed to mess up my sytstem...

P.S. thanks for taking the time to help debug this with me :)

[echasnovski]

So, after reading about git help, man, groff, and other more than I'd like, I pushed the desperate git-completion-man temporary branch to try and fix it. Could you try it out and see if completion works?

@aikow, also would you mind:

• Clarifying what type of "doesn't work" you mean here (and in the possible future)? There are now at least "hangs when trying to complete" and "does not hang but shows no completion".
• Creating a separate issue with your findings (as much as you have free time to provide)? This is both to not clutter this issue and for future reference.

---

Those x\bx (and possible _\bx) is an "old" way to format character as bold (and italic). The origin of this on Mac seems to be groff / grotty / or something like that. It seems to still try to format it with these symbols.

[tssm]

Hey @echasnovski, regarding how mini.git decides which sub-commands open in a split, I've been playing a bit with the command you gave me and found that reflog as well as stash are shown with git --list-cmds=builtins as well as git --list-cmds=main. I'm not sure why you are filtering by list instead, but reflog is listed (as well as remote, discussed above) if you add list-ancillarymanipulators, and stash if you add list-mainporcelain. Here is a list for reference.

I've also found that if I run either :Git stage -p, or :Git stash list their output appears as a notification, but the buffers are added to the list, so I have to kill them manually. Any command whose output is not handled as a split will result in the same behavior, I guess

[echasnovski]

Hey @echasnovski, regarding how mini.git decides which sub-commands open in a split, I've been playing a bit with the command you gave me and found that reflog as well as stash are shown with git --list-cmds=builtins as well as git --list-cmds=main. I'm not sure why you are filtering by list instead, but reflog is listed (as well as remote, discussed above) if you add list-ancillarymanipulators, and stash if you add list-mainporcelain. Here is a list for reference.

Yes, I know, I've read that file. Adding either builtins/main/list-ancillarymanipulators/list-mainporcelain for the task of "get list of commands that are intended to show users something instead of do something" is missing the point. Hence only "info" and "list-xxxinterrogators" are used.

I've also found that if I run either :Git stage -p, or :Git stash list their output appears as a notification, but the buffers are added to the list, so I have to kill them manually. Any command whose output is not handled as a split will result in the same behavior, I guess

I can not reproduce this neither with 'mini.notify' nor without it. I.e. there is no extra buffer created specifically to show the output of :Git stage -p. There is always the scratch buffer from 'mini.notify' present (for performance reasons), but that is it.

What do you use for vim.notify()?

[mehalter]

Out of curiosity is there a reason for mini.git's repo name to be mini-git instead of mini.git like all of the other separated mini plugins? It seems strange that it has a different naming convention. Is this because it is currently in a "beta" state and will be renamed to mini.git once it is fully released?