feat: add git reset action for git commits picker

[joelpalmer]

Adding a git reset action and making it available in the git_commits picker.

This PR:

• Adds a git_reset action
• Adds the above action to the git_commits picker
• Maps <c-r> to call the action in either normal or insert mode

Like similar actions, the git_reset action has a confirmation along with handling of the error and success cases and their messages. The default for git reset is --mixed. That behavior is continued here. If this PR is accepted, I'd like to follow-up with --soft and --hard options in a future PR. I personally have my local version hardcoded to --hard. But, that would probably surprise and upset many users if it were the default. Git's default is safe and friendly. 😄

The reason for adding the new action to the git_commits picker is because it's Telescope's git log picker. It is convenient, intuitive and awesome to reset to the selected commit. I've been using it locally for a while and it saves me from having to copy/paste the SHA or count backwards from HEAD. Who has time for all that? Telescope to the rescue as usual. 🔭

[Conni2461]

LGTM can we get some docs for the key mappings here

telescope.nvim/lua/telescope/builtin/init.lua

Lines 143 to 148 in 1386979

	--- Lists commits for current directory with diff preview
	--- - Default keymaps:
	--- - `<cr>`: checks out the currently selected commit
	---@param opts table: options to pass to the picker
	---@field cwd string: specify the path of the repo
	builtin.git_commits = require('telescope.builtin.git').commits

Similar to git_branches

[Conni2461]

Also i am interested, how do you wanna do configuring of --soft / --hard with opts? So require('telescope.builtin').git_commits({ reset = "hard" })? Just curious right now because i cant think of a better idea

[joelpalmer]

LGTM can we get some docs for the key mappings here

Absolutely! Pushed.

Also i am interested, how do you wanna do configuring of --soft / --hard with opts? So require('telescope.builtin').git_commits({ reset = "hard" })? Just curious right now because i cant think of a better idea

That's a good idea for it. I was still thinking about it. 😄

Thank you @Conni2461!

[tjdevries]

I don't see any reason not to do something like actions.git_reset_soft, actions.git_reset_mixed, actions.git_reset_hard and just having them all share the same implementation except for the argument sent to git.

The user can just map whatever one they want to override <c-r> OR can have separate keys for each one.

[joelpalmer]

Sweet. I like it. I'll update this accordingly.

[joelpalmer]

Updated per the above comment from @tjdevries.

This PR now has these actions (which share implementation) available in the git_commits picker:

• actions.git_reset_soft
• actions.git_reset_mixed
• actions.git_reset_hard

Keymaps:

• <C-r>m: resets current branch to selected commit using mixed mode
• <C-r>s: resets current branch to selected commit using soft mode
• <C-r>h: resets current branch to selected commit using hard mode

Docs have been updated to reflect these updates. 😃

[l-kershaw]

I'm not sure what @tjdevries and @Conni2461 would prefer, but to me it seems like a better user experience to just have <C-r> mapped to mixed reset by default and no mappings for the other reset modes. We would then mention in the docs (though I'm not sure where is the best place for this) that this can be remapped to another mode, or removed to implement multiple keymappings in the users preferred way.

This then doesn't overcomplicate things for new users, but allows "power users" to easily configure things how they want. Although it is then very important to have it be easily discoverable in the documentation that this is something that they can configure.

[joelpalmer]

it seems like a better user experience to just have mapped to mixed reset by default and no mappings for the other reset modes

Thanks for the feedback @l-kershaw! Either way works for me. As you mentioned or having all modes mapped.

We would then mention in the docs (though I'm not sure where is the best place for this) that this can be remapped to another mode, or removed to implement multiple keymappings in the users preferred way.

This then doesn't overcomplicate things for new users, but allows "power users" to easily configure things how they want. Although it is then very important to have it be easily discoverable in the documentation that this is something that they can configure.

For now, to be "easily discoverable", I've added documentation for the mappings to the Git Pickers → git_commits section of the README. The actions have documentation and also being mentioned in the README will aid in discoverability. This way, if we go with just defaulting <C-r> to mixed, then we can at least leave a mention of the other available actions in that Description section of the README.

[kkharji]

LGTM, Thanks @joelpalmer.

[joelpalmer]

Thank you @tami5!