Copying multiple hashes yields incorrect dotted range on nonlinear histories and consecutive selections

[naseschwarz]

Describe the bug
Copying multiple hashes that are consecutive in the gitui revlog display yields incorrect dotted range if the commit history is not linear.

To Reproduce
Steps to reproduce the behavior:

1. Build a test graph:

git init
touch a
git add -A
git commit -m 'a'
touch b
git add -A
git commit -m 'b'
git checkout HEAD~ -b c
touch c
git add -A
git commit -m 'c'
git checkout -
git merge --no-ff c

3. Start gitui
4. Switch to Log [2]
5. Select commit with message 'c'
6. Press space
7. Select commit with message 'b'
8. Press space
9. Press y to yank commits
10. On the result, run get rev-list '<copied text here>'
11. git rev-list only outputs one commit

Expected behavior
git rev-list lists the two selected commits

Screenshots
Constructed history:

Revlog with selection

Yanked commit sequence and rev-list output

Context (please complete the following information):

• OS/Distro + Version: Linux 6.13.6
• GitUI Version 0.27
• Rust version: 1.85

[naseschwarz]

I guess this is because of how marked_consecutive is computed in copy_commit_hash. It's just incorrect to assume that the linear history displayed in this view is a correct representation on which to compute dotted ranges.

[naseschwarz]

I've put in a patch to remove dotted range notation again in #2577.

It can easily be reintroduced again, but that should happen with more care. The simplest way to introduce it would be to use the same means for computing consecutiveness, but before yanking, generate a revwalk representing the suggested range and checking whether the set of commits in there and in the original selection congruent.