### PR Description
This PR includes 2 changes:
1. Bump golangci-lint version to `v2.4.0` from `v.2.2.1`
1. Bump Go version to `1.25.0`:
- Bump Go version to `1.25` in `go.mod`
- Bump Go version to `1.25` in `ci.yml`
- Bump base image to `golang:1.25` in `Dockerfile`
### Reference
- [Go 1.25 release note](https://tip.golang.org/doc/go1.25)
I find the command "Checkout previous branch" quite useful, and I use it
a lot. However, I'm unhappy with the visual feedback, so this PR
improves that a bit.
Previously, the feedback you got when pressing "-" was just a "Checking
out..." status in the bottom line. This was both easy to miss if you are
used to looking for an inline status in the branches panel, and it
didn't provide information about which branch was being checked out,
which can be annoying in very large repos where checking out takes a
while, and you only see at the end if you are now on the right branch.
Improve this by trying to figure out which branch was the previously
checked out one, and then checking it out normally so that you get an
inline status next to it (as if you had pressed space on it). There are
cases where this fails, e.g. when the previously checked out ref was a
detached head, in which case we fall back to the previous behavior.
Previously, the feedback you got when pressing "-" was just a "Checking out..."
status in the bottom line. This was both easy to miss if you are used to looking
for an inline status in the branches panel, and it didn't provide information
about which branch was being checked out, which can be annoying in very large
repos where checking out takes a while, and you only see at the end if you are
now on the right branch.
Improve this by trying to figure out which branch was the previously checked out
one, and then checking it out normally so that you get an inline status next to
it (as if you had pressed space on it). There are cases where this fails, e.g.
when the previously checked out ref was a detached head, in which case we fall
back to the previous behavior.
When you delete a branch, we call this function to determine whether we
need to ask for confirmation of not. We don't want to log this, because
it's not a command that a user would normally use as part of this
operation.
When you delete a branch, we call this function to determine whether we need to
ask for confirmation of not. We don't want to log this, because it's not a
command that a user would normally use as part of this operation.
In all other menus besides the keybindings menu it makes sense to hide
keybindings that match the confirmMenu binding. This is important to
make it clear which action will be triggered when you press the key.
In the keybindings menu this is different; the main purpose of that menu
is not to allow triggering commands by their key while the menu is open,
but to serve as a reference for what the keybindings are when it is not
open. Because of this, it is more important to show all bindings in this
menu, even if they conflict with the confirmMenu key.
This fixes a regression introduced in b3a3410a1a.
Fixes#4879.
In all other menus besides the keybindings menu it makes sense to hide
keybindings that match the confirmMenu binding. This is important to make it
clear which action will be triggered when you press the key.
In the keybindings menu this is different; the main purpose of that menu is not
to allow triggering commands by their key while the menu is open, but to serve
as a reference for what the keybindings are when it is not open. Because of
this, it is more important to show all bindings in this menu, even if they
conflict with the confirmMenu key.
This fixes a regression introduced in b3a3410a1a.
### PR Description
Remapping `keybinding.universal.confirm` from `<enter>` to something
like `y` is currently impossible because the same keybinding is also
used to confirm prompts (e.g. "New branch") and the search prompt. Fix
this by hard-coding enter for those; it doesn't really make sense to use
any other key for prompts.
While at it, add separate bindings for `confirmMenu` and
`confirmSuggestion` for those who would like to have different keys for
these. Of these, `confirmMenu` could be a little tricky because menus
are sometimes used purely as a choice (e.g. in "Amend commit attribute"
or the global keybindings menu), in which case you might want to use
`<enter>`, but other times as a substitute for a confirmation (e.g. for
"Delete branch"), in which case you might want to remap to `y`. I don't
have a great idea what to do about that, to be honest. Feedback welcome.
In this PR we only take care of Confirm, which many people seem to be
concerned about. We might consider doing something similar for Esc, but
it seems less urgent, and I'm out of time now. 😄
This seemingly simple change required some serious refactoring under the
hood, so thorough testing would be good to ensure we didn't break
anything.
Closes#2611Closes#2767Closes#3471
Related: #2768
This is needed when remapping the confirmMenu key to, say, "y", and there's a
menu that has an item with a "y" binding. This already worked correctly (confirm
takes precedence, as desired), but it's still confusing to see the item binding.
It seems useful to have the flexibility to remap "enter" in confirmations to
"y", but keep "enter" for menus and suggestions (even though we sometimes use
menus as confirmations, but it's still good to give users the choice).
This one doesn't make a difference in practice because we don't remap the key in
tests, but if we would, then this would no longer work correctly. It's just more
correct this way.
The universal.confirm keybinding is the wrong one to use for this, we want
universal.goInto instead. They are both bound to "enter" by default, but when
remapping confirm to "y" we don't want to use that for entering worktrees.
Rebinding the universal.confirm keybinding currently doesn't make sense, because
the rebound key would also be used for editable prompts, which means you would
only be able to bind it to a ctrl key (not "y", which is desirable for some
people), and also it would allow you to enter a line feed in a branch name.
Fix this by always using enter for editable prompts.
So far, confirmations and prompts were handled by the same view, context, and
controller, with a bunch of conditional code based on whether the view is
editable. This was more or less ok so far, since it does save a little bit of
code duplication; however, now we need separate views, because we don't have
dynamic keybindings, but we want to map "confirm" to different keys in
confirmations (the "universal.confirm" user config) and prompts (hard-coded to
enter, because it doesn't make sense to customize it there).
It also allows us to get rid of the conditional code, which is a nice benefit;
and the code duplication is actually not *that* bad.
This fixes a crash in an interactive rebase when there's a merge command
in the rebase-todo file that doesn't have a comment. I don't know under
what circumstances this can happen; git itself doesn't produce these,
but it is theoretically possible for the user to do this manually by
doing `git rebase --edit-todo`, or third-party tools could do it too.
We had one user report a crash because of this, so it seems worth fixing
it.
Closes#4858.
This fixes a crash in an interactive rebase when there's a merge command in the
rebase-todo file that doesn't have a comment. I don't know under what
circumstances this can happen; git itself doesn't produce these, but it is
theoretically possible for the user to do this manually by doing `git rebase
--edit-todo`, or third-party tools could do it too.
We had one user report a crash because of this, so it seems worth fixing it.
### PR Description
When filtering by file path, dropping a range selection of stashes would
drop the wrong ones if those stashes would be noncontiguous in the
unfiltered list.
