Drag-and-drop rebase also requires exactly 2 commits. Personally, my main issue is with discoverability. As long as it's discoverable, I don't have an opinion on whether this is done with discontiguous 2-commit selections vs range-selection with some sort of contiguity check.

We also run into this regularly, but in our case it was more frustrating because we didn't think to use "Reveal commit". We did:

1. Type into filter box and find the correct commit

2. Select the relevant commit

3. Hit "x" on the filter.

This seemed like it should work, because we had these expectations:

1. The selection in the "Commits" window would be retained

2. The "Commits" window would be scrolled to keep (at least a portion of) the selection in view

#1 seems like a fairly fundamental user expectation, and it was quite surprising (and frustrating) for it to be violated. We didn't think to use Pierre's "reveal commit" workaround, because it seemed to be already revealed. So we resorted to "remember the commit date and perform a manual search after clearing the filter".

Obviously, the speed-search is the most streamlined UX, but it's quite undiscoverable. Improving that would be fantastic; but I think it would also be good to implement #1 despite the fact that revealing commits is a potentially-expensive operation. (Probably the filtered view would also have to avoid automatically selecting the first commit)

Yes please! We use custom tools a lot for things like "amend this (non-HEAD) commit" or "push this (non-branch-head) ${commit} to Gerrit".