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.