Keybindings broken by v0.41.0

[uvb1]

Keybindings that were working before the v0.41.0 release are now causing an error window even though they still appear to work in the background.

I read the v0.41.0 Release Notes and even though it mentions some keybinding breakages, it doesn't seem relevant to my issue.

I've also read the README and the keybinding sections of the docs directory and haven't found anything relevant.

My config is below. It was working before the release and now I'm encountering this breakage, but haven't made any changes.

To Reproduce
config.yml contents:

keybinding:
  universal:
    scrollUpMain: '<c-b>'
    scrollDownMain: '<c-f>'
  files:
    openStatusFilter: '<c-t>'

Steps:

1. Set focus in the Files section.
2. Press Control-f
3. A box appears in the middle of the screen with the title "Error". The text in the box differs depending on the repo status
   • "No deleted lines in diff", or
   • "Multiple base commits found...", etc

Expected behavior
The text in the main window should scroll down as it had previously.

Version info:
commit=3675570a391b1a49ddd198b4c7e71e17701d4404, build date=2024-03-23T09:09:11Z, build source=binaryRelease, version=0.41.0

git version 2.39.3 (Apple Git-146)

[Stefan Haller]

This is not really a bug. We added a new command in 0.41.0 whose default keybinding (<c-f>) conflicts with yours. To fix this, add

keybinding:
    files:
      findBaseCommitForFixup: <disabled>

or some other key that doesn't conflict with yours. Background: when two commands have the same keybinding, it is somewhat arbitrary which one wins. In this case, it happens to be the findBaseCommitForFixup command which wins over scrollDownMain.

Now, you could argue that it would be desirable for user-configured keybindings to take precedence over default keybindings, so that you don't have to do this. That would be an enhancement request, I guess.

[uvb1]

Thank you for the rapid response. That corrected the issue.

When something was working, the user makes no changes, a version updates, and now what was working no longer is - that is "breaking backward compatibility". If the change wasn't communicated, I see that as a bug. From a user's perspective there is no difference between a code issue and a functionality breakage - the effective impact is the same. However, since the repo is still in beta (major version: 0), this type of breaking backward compatibility is expected. The release notes did call out that this was a very large release with some breaking changes.

The software is great and I'm grateful for the hard work, just disappointed that this particular change, or a generic set of instructions on how to diagnose and fix such potential conflicts, wasn't provided as part of the release. This is a great tool and its frustrating when the day is interrupted by something like this. Especially something that can't be easily located in the README or release notes.

I didn't see findBaseCommitForFixup in the keybinding documentation so if I were to encounter another keybinding conflict, I'm not sure I would still know how to find the conflict. If I'm missing something, please let me know.

I've created an enhancement request as you suggested since it didn't seem like you were going to move forward with it. Hopefully this helps anyone else who may encounter a similar breakage.

Thanks!