Closed echasnovski closed 5 months ago
I just wanna share something cool: In case you've diverged some commits from main
and want to compare to main
instead of your HEAD
, git read-tree main
works nicely. You go back by git reset
, which leaves your changes intact off course. Integrated into some nice (lazyspec) keymaps, you can even pick the base like this for instance:
{
"<leader>gb",
function()
require("mini.extra").pickers.git_branches({}, {
source = {
choose = function(item)
vim.fn.system("git read-tree " .. item:match("^%*?%s*(%S+)"))
end,
},
})
end,
desc = "Set git base to a branch",
},
{
"<leader>gc",
function()
require("mini.extra").pickers.git_commits({}, {
source = {
choose = function(item)
vim.fn.system("git read-tree " .. item:match("^(%S+)"))
end,
},
})
end,
desc = "Set git base to a commit",
},
{
"<leader>gr",
function()
vim.fn.system("git reset")
end,
desc = "Reset git base",
},
I get this error when I enable mini.diff.
I get this error when I enable mini.diff.
What Neovim version do you use and how did you install it?
I use:
nvim v0.10.0 git v2.45.1 os pop_os
I use nvim app image, and moved it into /usr/local/bin
On Mon, May 20, 2024 at 9:47 AM Evgeni Chasnovski @.***> wrote:
I get this error when I enable mini.diff.
What Neovim version do you use and how did you install it?
— Reply to this email directly, view it on GitHub https://github.com/echasnovski/mini.nvim/issues/773#issuecomment-2120499539, or unsubscribe https://github.com/notifications/unsubscribe-auth/AWVSELPPK2MQCN3DOLU4HKDZDH5IVAVCNFSM6AAAAABFNEERVCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMRQGQ4TSNJTHE . You are receiving this because you commented.Message ID: <echasnovski/mini .@.***>
You probably did not update 'mini.diff'. Make sure to update it to have at least this change.
I still see the same issue after update.
This is my nvim config https://github.com/justEstif/mini-nvim
This is my nvim config https://github.com/justEstif/mini-nvim
It does not look like you updated because this line is meant to prevent plugin from being updated. It seems that you copied this from my config, which I have enabled because I make 'mini.nvim' updates myself. Remove checkout = 'HEAD'
, restart Neovim, and run :DepsUpdate
.
Awesome. Thanks a lot. Very happy with the direction of the project, and excited to see what's next.
Also, currently mini.statusline works with gitsigns. Are you planning to add support for mini.diff?
Awesome. Thanks a lot. Very happy with the direction of the project, and excited to see what's next.
Also, currently mini.statusline works with gitsigns. Are you planning to add support for mini.diff?
I am quite literally writing that code right now :)
is it possible to select stuff with the text object? I changed it to ih
and other things that don't clobber with anything and vih
(or whatever else I've tried) doesn't visualize stuff. IMO would be really handy to have.
I'm very much enjoying the module, thanks!!
is it possible to select stuff with the text object? I changed it to
ih
and other things that don't clobber with anything andvih
(or whatever else I've tried) doesn't visualize stuff. IMO would be really handy to have.I'm very much enjoying the module, thanks!!
Visual mode for textobject is not supported. Mostly because it is rarely an end goal in itself. See this comment for more info.
the goal I had in mind was moving hunks e.g. with mini.move - I have my mini.comment text object mapped to ic
for much the same reason (iirc it also can't do this with the default text object mapping)
I am quite literally writing that code right now :)
@justEstif, 'mini.statusline'' default content now supports both 'mini.diff' (with the new section_diff()
) and the new 'mini.git' (with the section_git()
).
the goal I had in mind was moving hunks e.g. with mini.move - I have my mini.comment text object mapped to
ic
for much the same reason (iirc it also can't do this with the default text object mapping)
Hmm... I did not think about this use case. My suggestion right now would be either to fall back to dgh
(or dih
in your use case) and later pasting. Or make an explicit similar to how it is done internally.
But I'll spend some time thinking if this is worth a better out of the box support
I'm not entirely sure if this is a bug but calling toggle_overlay() in a buffer that's been disabled with toggle() errors. I expected to just re-enable then turn on the overlay.
I'm not entirely sure if this is a bug but calling toggle_overlay() in a buffer that's been disabled with toggle() errors. I expected to just re-enable then turn on the overlay.
It is an intended design choice. Either it was not enabled automatically or disabled manually, it is worth showing that there can be no overlay in the current buffer. Requiring a manual toggle seems to be a low price.
This can be made into a custom mapping which tries to enable if disabled and later toggles overlay.
Most of the time I just want to stage or reset the git hunk I'm currently at. To do that, based on my current mappings, I need to type ghs
/ghr
and then gh
. Since I have this muscle memory from using gitsigns. I want to ask that is it possible set ghs
to stage the current hunk immediately?
I tried something like this:
local MiniDiff = require 'mini.diff'
MiniDiff.setup {
mappings = {
apply = 'ghs_',
},
}
vim.keymap.set('n', 'ghs', 'ghs_gh')
But it didn't work.
Most of the time I just want to stage or reset the git hunk I'm currently at. To do that, based on my current mappings, I need to type
ghs
/ghr
and thengh
. Since I have this muscle memory from using gitsigns. I want to ask that is it possible setghs
to stage the current hunk immediately?I tried something like this:
local MiniDiff = require 'mini.diff' MiniDiff.setup { mappings = { apply = 'ghs_', }, } vim.keymap.set('n', 'ghs', 'ghs_gh')
But it didn't work.
It is not possible to map ghs
to both act as operator (wait for textobject/motion) and applying current hunk immediately.
There are two issues with the snippet above:
ghs
work immediately, there should not be any other mapping that starts with ghs
in Normal mode. In that setup there are ghs_
(operator) and ghs
(to apply current hunk). Typing ghs
will work but not immediately: there has to be a pause of 'timeoutlen' milliseconds so that Neovim can understand that you don't want to press _
.vim.keymap.set()
by default treats keys in right hand side as if they don't have any other mappings (i.e. come from default; i.e. not remapped). Use { remap = true }
to treat them as remapped.The following setup seems to work:
require('mini.diff').setup({
mappings = {
apply = 'gh_',
},
})
vim.keymap.set('n', 'ghs', 'gh_gh', { remap = true })
@echasnovski Perfect, thank you for taking time and explaining this to me.
Hi, sometimes I want to copy some text from hunks, but I can't do that in extmark_based hunk message, the only way is to reset, copy and undo.
@xzbdmw, this is now possible with "yank"
action in do_hunks()
and operator()
. The reason it does not have default mapping is because there is no good one which does not interfere with default 'gh' and 'gH'. So it is left to users to make mappings. Here is an example of yanking reference lines of hunk range under cursor. I personally used it today, so I think it is a win :)
the goal I had in mind was moving hunks e.g. with mini.move - I have my mini.comment text object mapped to
ic
for much the same reason (iirc it also can't do this with the default text object mapping)
@BeauSLM, the textobject mappings now also works in Visual mode if there is no conflicts. Same as textobject in 'mini.comment'. Thanks for the suggestion and compelling use case!
The following is not a big issue because I don't often need it, and when I do there is a workaround, but I thought I would still mention it.
I sometimes find myself wanting to stage diff hunks that are loaded in the quickfix list (for example, by using git-jump and then filtering the list with :Cfilter
).
One way to accomplish this is with :cdo normal ghgh
, but this will fail for entries in buffers where MiniDiff hasn't been enabled yet. I tried adding :lua MiniDiff.enable()
or :edit
before :normal ghgh
, but that didn't work. Enabling all buffers in a separate preliminary command with :cfdo lua MiniDiff.enable()
does work though, and that's a totally viable solution for me.
Yeah, both staging/applying hunk and hunk textobject require set reference text in the buffer. If buffer is not enabled, there is no reference text. So this will remain to work like this and it is good to have a known workaround.
May I also interest you in :Git add .
from the new 'mini.git'? :)
May I also interest you in :Git add . from the new 'mini.git'? :)
In the cases I'm thinking of I would need Git add -p
, because I would want to selectively stage some hunks and not others in the same file.
Anyway, as I said above, it doesn't happen that often, and when it does it can easily be handled manually with ghgh]q.]q.]q.]q.
... throughout the whole list (or record ghgh]q
as macro and then QQQQQ
...!) And if that's still too long, then there's the :cdo
option mentioned above :)
Is there a way to compare two branches different from HEAD in order to incorporate those changes into HEAD?
I want to pick changes from branch A that haven't been merged into the main. Therefore, my goal is to create branch B, switch to branch B, compare the differences between A and main, and selectively integrate changes from A.
Is there a way to compare two branches different from HEAD in order to incorporate those changes into HEAD?
I want to pick changes from branch A that haven't been merged into the main. Therefore, my goal is to create branch B, switch to branch B, compare the differences between A and main, and selectively integrate changes from A.
Visualizing difference should be possible if you can get proper reference text (i.e. state of main
, if I understood correctly). This can be done with git show main:relative/path/to/current/file
CLI command. There are several methods to get the output of CIL call: vim.fn.system()
or vim.system(...):wait().stdout
.
Being able to stage hunks is a bit more tricky. For inspiration you can take a look at this comment.
But to be honest, this task feels more suitable for a full Git client.
Have a "hover" preview option to show a single hunk diff. Essentially show what the overlay shows but in a hover that I can quickly view without turning on the entire overlay feature on/off.
No, I don't see it be valuable enough to warrant separate functionality. Besides, going away from "preview single hunk" was one of the goals of 'mini.diff' for me: I didn't really like its workflow. So toggling overlay is the method to preview hunks in 'mini.diff'.
i sometimes want to copy text from the deleted hunks, is that still possible using 'mini.diff's workflow with overlay?
@xzbdmw hmm but i don't always want to copy the entire hunk. with floating window i can jump there then copy, ie. yif
to copy function invocation and q
to close
i sometimes want to copy text from the deleted hunks, is that still possible using 'mini.diff's workflow with overlay?
... hmm but i don't always want to copy the entire hunk. with floating window i can jump there then copy, ie.
yif
to copy function invocation andq
to close
I am afraid the answer here is "No; only whole previous text can be yanked". Making this possible will require allowing cursor to navigate inside deleted/changed portion of a hunk. This needs a lot of new code and is against current design.
With the release of 0.13.0, 'mini.diff' is now out of beta-testing. Thanks to brave souls who got the courage to switch from battle-tested 'gitsigns.nvim'! It means a lot!
Please leave your feedback about new mini.diff 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):
Thanks!