I've optimised for muscle memory backwards compatibility here:
- Outside interactive rebase: press 'f' then instead of a confirmation
panel, a menu appears where you can choose to keep the selected commit's
message
- Inside interactive rebase: press 'f' then press 'c' to see the menu
for keeping the message, where if you press 'c' again it will retain the
current message. so 'fcc' is the chord to press.
We're also now showing the -C flag (which is what enables the behaviour)
against the todo.
I've picked the 'c' keybinding because 'C' was taken and it corresponds
to the flag. Previously that showed a warning about a change in
keybinding for cherry picking but it's been ages since we've made that
change so I'm happy to retire it.
Not used yet, we pass an empty string everywhere, to match the previous
behavior. Just extracting this into a separate commit to make the next one
smaller.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
It's been ages since we changed the key, users should hopefully be used to it by
now, and we want to reuse the key for something else later in the branch.
Co-authored-by: Stefan Haller <stefan@haller-berlin.de>
On very large screens they would get ridiculously wide.
The limits we chose here are a little arbitrary:
- 80 for confirmations and prompts
- 90 for menus
- auto-wrap width plus 25 for the commit message editor (or 100 if
auto-wrap is off)
On very large screens they would get ridiculously wide.
The limits we chose here are a little arbitrary:
- 80 for confirmations and prompts
- 90 for menus
- auto-wrap width plus 25 for the commit message editor (or 100 if auto-wrap is
off)
To reproduce: open the keybindings menu ('?'), press '>' to select the
last line, esc to close it, open it again. The view would appear still
scrolled down, so the selected first line was out of view. Even worse,
if you open a different, shorter menu (e.g. the "View upstream reset
options..." menu in the Files panel), you'd only see the Cancel item,
the other ones were scrolled out of view.
This is a regression introduced with efd4298b5e (#5134).
To reproduce: open the keybindings menu ('?'), press '>' to select the last
line, esc to close it, open it again. The view would appear still scrolled down,
so the selected first line was out of view. Even worse, if you open a different,
shorter menu (e.g. the "View upstream reset options..." menu in the Files
panel), you'd only see the Cancel item, the other ones were scrolled out of
view.
This is a regression introduced with efd4298b5e (#5134).
When marking commits as good or bad during a bisect, a "git rev-list"
call would appear in the Command log. This is confusing, it's an
internal detail that is not interesting for the user to see.
When marking commits as good or bad during a bisect, a "git rev-list" call would
appear in the Command log. This is confusing, it's an internal detail that is
not interesting for the user to see.
### PR Description
- Updated `actions/github-script` from `v7` to `v8` in
`.github/workflows/close-issues.yml`
- Updated `actions/setup-go` from `v5` to `v6` in
`.github/workflows/release.yml`
- Updated `golangci/golangci-lint-action` from `v8` to `v9` in
`.github/workflows/ci.yml`
- Updated `actions/checkout` from `v4` to `v6` in
`.github/workflows/codespell.yml`
- Updated `actions/checkout` from `v4` to `v6` in
`.github/workflows/release.yml`
- Updated `peter-evans/create-pull-request` from `v7` to `v8` in
`.github/workflows/sponsors.yml`
- Updated `actions/download-artifact` from `v4` to `v7` in
`.github/workflows/ci.yml`
- Updated `actions/checkout` from `v4` to `v6` in
`.github/workflows/ci.yml`
- Updated `actions/checkout` from `v4` to `v6` in
`.github/workflows/sponsors.yml`
- Updated `actions/setup-go` from `v5` to `v6` in
`.github/workflows/ci.yml`
The changes ensure that the GitHub Action workflows are using the latest
versions of the actions, which include improved functionality and
compatibility. These updates will be tested in the CI pipeline of the
pull request.
If the ctrl-f function (Find base commit for fixup) finds a base commit
plus a bunch of fixup! commits for that base commit, it ignores those
fixups and selects the base commit. For the purpose of creating another
fixup commit on top this is always what you want, so I'm doing this
without adding a confirmation. If the user presses shift-A after that to
amend their changes though, they are guaranteed to get conflicts, so for
that case a warning might be useful; however, I find it unlikely that
users will want to amend changes to a commit that they already created
fixups for, so I'm just hoping that this won't happen in practice.
This implementation is a bit stricter than #5201, in that it only
ignores fixups if the first found commit is not a fixup itself; because
if it is, it's not clear whether the user wants to create another fixup
for both on top, or amend the changes into each one, in which case they
need to be staged individually.
When opening a PR, a "git ls-remote" call would appear in the Command
log. This is confusing, it's an internal detail that is not interesting
for the user to see.
When opening a PR, a "git ls-remote" call would appear in the Command log. This
is confusing, it's an internal detail that is not interesting for the user to
see.
This provides two fixes:
- proper handling of keypad keys on certain terminals (e.g. iTerm2)
- fix problems pasting certain emojis or east asian text on Windows
Terminal
Fixes#5171Fixes#5173
This provides two fixes:
- proper handling of keypad keys on certain terminals (e.g. iTerm2)
- fix problems pasting certain emojis or east asian text on Windows Terminal
When searching (not filtering) in a list view using `/`, moving the
selection now updates the "x of y" indicator of the search results to
the last one before the selection. Pressing `n` again searches from
there rather than from the previously shown result.
Also see corresponding gocui PR at
https://github.com/jesseduffield/gocui/pull/95.
Checking out a file discards all local modifications to that file;
checking out a directory discards modifications to all files in that
directory. This can result in lost work if the user isn't aware of this.
Instead of showing a confirmation (to which the user might press enter
too hastily, still losing their work), or showing a menu with
auto-stash/discard options, we simply show an error. The assumption is
that this is an unusual situation that users won't run into often, and
if they do, it's easy enough to manually address it by stashing or
discarding the changes as appropriate.
Fixes#5142.
Jesse Duffield
Stefan Haller
Padraic Slattery
github-actions[bot]
mricherzhagen