feat: Make Fixup Helper ignore fixup-commits, if multiple base commits are found.

[mricherzhagen]

PR Description

Sometimes I run into the "Multiple base commits found" error message, when I'm using the ctrl-f function to find the commit to fixup. But most often than not it lists the base commit I want and a bunch of unsquashed fixup! commits.

This PR makes lazygit check for that case and then offers the only non-fixup commit found with a warning/confirmation dialog.

This PR shares a commit with #5193 that moves the creation of the Handler function into a helper function.

Please check if the PR fulfills these requirements

• Cheatsheets are up-to-date (run go generate ./...)
• Code has been formatted (see here)
• Tests have been added/updated (see here for the integration test guide)
• Text is internationalised (see here)
• If a new UserConfig entry was added, make sure it can be hot-reloaded (see here)
• Docs have been updated if necessary
• You've read through your own file changes for silly mistakes etc

[stefanhaller]

This is a very welcome change; I frequently run into this situation too, and find it annoying.

However, the implementation is not quite good enough: you are only looking for any fixup! commits, but it's important that you only consider fixup commits for the same base commit. (This needs a prefix comparison, since the subject of the fixup might be shorter than the original.)

Also, once you detected this situation, I think we should select the base commit without showing a confirmation. I find the confirmation more confusing than helpful actually.

[mricherzhagen]

Added the prefix check and a testcase for both cases. I left the confirmation for the case where the fixup commits do not match the base commit because most often than not you want to fixup anyway.

Thinking about it another option for all of those cases where there isn't a distinct base commit would be to show a list of all the base commits it found and allow you to select which commit to jump to.

[stefanhaller]

I left the confirmation for the case where the fixup commits do not match the base commit because most often than not you want to fixup anyway.

This doesn't make sense. Finding multiple commits that are fixups for different base commits needs to be an error as before, just like finding those different base commits itself is.

I had a closer look at your implementation and found a few other things that I would do differently (for example, it is important to handle the case where there are chains of fixup! fixup! squash! Subject). For me it was easier to start a new PR from scratch rather than work on getting yours into shape, I hope you don't mind. Please have a look at #5210.

Thinking about it another option for all of those cases where there isn't a distinct base commit would be to show a list of all the base commits it found and allow you to select which commit to jump to.

Funny, I also thought about that occasionally. But again, I think this would be abusing the command as a blame tool, it never makes sense to amend changes or create fixups for one of those commits in such a case.

[mricherzhagen]

Thinking about it another option for all of those cases where there isn't a distinct base commit would be to show a list of all the base commits it found and allow you to select which commit to jump to.

Funny, I also thought about that occasionally. But again, I think this would be abusing the command as a blame tool,

It could be a separate command, maybe. Sadly ctrl-shift-f is already blocked with terminal behavior.
Though it is probably not easy, because then you don't want to show only a list of commits, but scroll through the commits with their changes?
Idea: Maybe it could be implemented more like the /-Search, so you can then jump between the found commits with n/shift-n. Then it wouldn't require a completely new UI?

it never makes sense to amend changes or create fixups for one of those commits in such a case.

I think the user should be the judge of that. The command wouldn't force them to create a fixup or amend them. Just give them something to ponder about.

[stefanhaller]

It could be a separate command, maybe.

Yes, that was my point, it's more of a blame-like command. I have a lot of thoughts about that, but here is not the place to discuss these. Maybe I'll find the time some day to write them up as an issue.

it never makes sense to amend changes or create fixups for one of those commits in such a case.

I think the user should be the judge of that.

I disagree. So far it has been the philosophy of the ctrl-f command to only present results that it knows are good ones, and error out if there is a chance that they are not. I'm not going to change that. And in this particular case, chances are very high that they are not.