Add non-contiguous commit selection for custom commands

[ruudk]

PR Description

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

This feature allows users to select multiple commits that are not adjacent to each other, making them available to custom commands via the new SelectedCommits template variable.

Previously, lazygit only supported contiguous range selection via SelectedCommitRange (with .From and .To hashes). This works well for sequential commits but doesn't support selecting specific commits scattered throughout the history (e.g., commits A, C, and E while skipping B and D).

This limitation made it difficult to create custom commands that operate on arbitrary sets of commits, such as exporting specific commits to another tool for review.

1. Mark commits using:

   • Press 'z' to toggle mark on the currently selected commit
   • Option+Click (Alt+Click) on commits to mark/unmark them

2. Use in custom commands via SelectedCommits: ```yaml customCommands:

   • key: 'X' context: 'commits' command: "echo '{{ range .SelectedCommits }}{{ .Hash }} {{ end }}'" output: popup description: 'Show selected commit hashes' ```

Behavior notes:

• Normal click clears all marks (standard selection behavior)
• First Option+Click marks both the current selection and clicked commit
• Subsequent Option+Clicks toggle individual marks
• Marked commits are visually highlighted
• Works in commits, reflog, and sub-commits contexts

[stefanhaller]

I don't want to add yet another way to mark things as selected; we have too many already. Also, if we were to do this, it should work for normal operations as well, not just custom commands; currently this looks like you might perform lazygit commands such as "drop" or "reset author" on the marked commits (which might actually be useful), but you can't. But no, I don't want to support this kind of non-contiguous multi-selections at this point; there are too many questions about how exactly these would work, and how they would interact with range selections.

How about we expose the cherry-picked commits to custom commands? This sounds like it would allow you to achieve what you want, and should be easy to do. The workflow would be similar to what you have in your branch, except that you use shift-C to mark the commits; and it has the advantage that we don't have to add new concepts.

[ruudk]

How about we expose the cherry-picked commits to custom commands? This sounds like it would allow you to achieve what you want, and should be easy to do. The workflow would be similar to what you have in your branch, except that you use shift-C to mark the commits; and it has the advantage that we don't have to add new concepts.

Nice, when I made this PR I also did consider this. One reason I went for this approach instead of building on cherry-pick, was that from the custom command perspective, there is no way to reset the mark-as-cherry-pick state. Do you have an idea to automate that?

[stefanhaller]

One reason I went for this approach instead of building on cherry-pick, was that from the custom command perspective, there is no way to reset the mark-as-cherry-pick state. Do you have an idea to automate that?

I'd have thought it's ok to require the user to do that manually after invoking the custom command (by hitting esc).

Also, I don't see any code in your current approach that does this for your custom z selection, either, or did I miss something?