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!

[pkazmier]

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?

See this thread on reddit: https://www.reddit.com/r/neovim/comments/1cxbegq/comment/l532r3i/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

From @echasnovski:

I was baffled yesterday when I realized that GitHub does not allow '.git' suffix. So had to go with 'mini-git'. Soooo frustrating to break the system :(

[tssm]

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

Ah, got it. I guess my confusion comes from the fact that log is listed, and unless I'm missing something, it only shows something. I hope at some point you reconsider adding support for commands that only show stuff (help wanted?), as IMO that's super useful, as navigating the output can be quickly done with plain old Vim commands (the very reason I miss reflog and stash)

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

After digging a bit I realized I messed up my setup, sorry for the false alarm 🙈

[echasnovski]

I guess my confusion comes from the fact that log is listed, and unless I'm missing something, it only shows something.

I'd say so too, yeah. Hence it is present in "list-info".

I hope at some point you reconsider adding support for commands that only show stuff (help wanted?), as IMO that's super useful, as navigating the output can be quickly done with plain old Vim commands (the very reason I miss reflog and stash)

It is already there, at least according to how Git itself categorizes subcommands: reflog is ancillarymanipulators, stash is just mainporcelain.

I think allowing explicit splitt command modifiers to force command output to be shown in a separate buffer is a robust and universal solution to the "make this subcommand show in a split" problem.

If you want a more automated approach, I'd suggest custom mappings and command line abbreviations.

[pBorak]

What are your thoughts on Fugitive's Gedit command? Does it align with the mini-git philosophy? I often find myself wanting to see how a file looked at a specific git revision. For example, Gedit HEAD~3:% allows me to do this. Or maybe I can already accomplish it somehow with current mini-git functionality?

[echasnovski]

What are your thoughts on Fugitive's Gedit command? Does it align with the mini-git philosophy? I often find myself wanting to see how a file looked at a specific git revision. For example, Gedit HEAD~3:% allows me to do this. Or maybe I can already accomplish it somehow with current mini-git functionality?

This particular use case of "see how a file looked at a specific git revision" can be done with :Git show, i.e. Git show HEAD~3:%. It has special treatment in that it also tries to detect the filetype of the output and thus have the proper highlighting/autocommands/etc.

Another close but slightly different use case of "see how a file looked before/after the change of this diff" is resolved by show_diff_source() (and also in show_at_cursor() by extension). See video demo of how it can be utilized with a single mapping.

It looks like :Gedit is indeed close to :Git show, but with a bit more integrations.

[aikow]

This might just deserve an issue again (just let me know, and I'll happily create a detailed issue), but I wanted to make sure whether this is in-scope for mini.git first.

Using vim-fugitive I get prompted to enter my GPG key password when doing anything that requires the key. I currently have the pinentry-mode loopback option set in my gpg.conf file. However, when doing the same tasks using mini.git the command just fails because the GPG key could not be unlocked.

As an unrelated note, would it be possible (or would it make sense) to add a function to MiniGit that automatically re-runs the command for a buffer? I found that I occasionally like to keep open a semi-complicated git log command, like git log --all --decorate --graph --oneline. Whenever I make a change, I have to rerun the command by either typing it out, or by searching through my command history. However, I noticed that the buffer name of the output buffer already seems to store the command that was run, so it should be quite easy to just add a function to refresh the output... If this is out-of-scope though, that's completely fine, although at least having a buffer scoped variable that stores the run command would be nice, so that I could easily implement a command myself.

[echasnovski]

Using vim-fugitive I get prompted to enter my GPG key password when doing anything that requires the key. I currently have the pinentry-mode loopback option set in my gpg.conf file. However, when doing the same tasks using mini.git the command just fails because the GPG key could not be unlocked.

I also sign commits using GPG with pinentry-program /usr/bin/pinentry-gtk-2 in my 'gpg-agent.conf'. It works for me right now. I have . If you can tell me the full GPG-Git setup, I'll try to reproduce and see if it is feasible to work with 'mini.git'.

As an unrelated note, would it be possible (or would it make sense) to add a function to MiniGit that automatically re-runs the command for a buffer?

This looks like a bit too specific functionality. Relying on command in output buffer name is not really reliable for at least these reasons:

• It doesn't contain information about working directory inside which that command should be executed (which depends on the buffer and its Git root).
• Not all commands result in a split (thus don't have buffer name from which to extract the command).

I think the best suggestion here is to make it easier to repeat frequent commands using common Neovim approaches:

• Create a mapping (like <Leader>gl for "Git Log").
• Use @: to execute the latest command.
• Use smarter history search. For example, type :Git followed by <C-p> to search only through commands that start with :Git. Or use MiniExtra.pickers.history() like Pick history scope=":".

[aikow]

I also sign commits using GPG with pinentry-program /usr/bin/pinentry-gtk-2 in my 'gpg-agent.conf'. It works for me right now. I have . If you can tell me the full GPG-Git setup, I'll try to reproduce and see if it is feasible to work with 'mini.git'.

I often have to sign commits from a server, so using pinentry-mode loopback was the only way I was able to get git to even ask for a password instead of just failing. That line is the only line in my gpg.conf file, and the rest of my GPG setup should be pretty standard, I just have configured git to automatically sign commits by default instead of manually using the -s flag. I'll try taking a look at vim-fugitive to see what they do differently.

It doesn't contain information about working directory inside which that command should be executed (which depends on the buffer and its Git root).

It should be fairly simple to add the information needed to rerun a command to a buffer-scoped variable, similar to the minigit_summary variable (coming from someone who just briefly looked at the source code, so maybe not the case). That could include cwd, env, and the actual command in a lua list. However, for those to be useful, I guess you would also need to expose some of the helper functions...

Not all commands result in a split (thus don't have buffer name from which to extract the command).

I was mainly thinking of having a buffer open that has the output of git log --... with a bunch of format options, and being able to update the buffer automatically by using something roughly akin to :lua MiniGit.run_cmd(vim.b.minigit_command). That way, I don't have to manually close the old buffer, rerun the command, and move the buffer to the position it was previously.

Creating custom keymappings for certain git commands helps, but that doesn't cover the (possibly rare) use case of having a one-off git command that you need to run multiple times.

I'll respect your decision though after this, I just felt like I might have not stated my idea clearly enough 😀 .

[echasnovski]

I often have to sign commits from a server, so using pinentry-mode loopback was the only way I was able to get git to even ask for a password instead of just failing. That line is the only line in my gpg.conf file, and the rest of my GPG setup should be pretty standard, I just have configured git to automatically sign commits by default instead of manually using the -s flag. I'll try taking a look at vim-fugitive to see what they do differently.

I'll take a look.

I was mainly thinking of having a buffer open that has the output of git log --... with a bunch of format options, and being able to update the buffer automatically by using something roughly akin to :lua MiniGit.run_cmd(vim.b.minigit_command). That way, I don't have to manually close the old buffer, rerun the command, and move the buffer to the position it was previously.

Indeed, this type of workflow will not be supported in 'mini.git'. The best advice I can give is to write your own wrapper which will utilize :Git log -- %.

[echasnovski]

With the release of 0.13.0, 'mini.git' is now out of beta-testing. Thank you all for the early testing and useful feedback! It means a lot!