Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
naseschwarz opened this issue Mar 20, 2025 · 2 comments · May be fixed by #2577
Labels
bug Something isn't working
Milestone

Comments

@naseschwarz
Copy link
Contributor

naseschwarz commented Mar 20, 2025

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

Expected behavior
git rev-list lists the two selected commits

Screenshots
Constructed history:

Image

Revlog with selection

Image

Yanked commit sequence and rev-list output

Image

Context (please complete the following information):

  • OS/Distro + Version: Linux 6.13.6
  • GitUI Version 0.27
  • Rust version: 1.85
@naseschwarz naseschwarz added the bug Something isn't working label Mar 20, 2025
@naseschwarz naseschwarz changed the title Copying multiple hashes yields incorrect dotted range Copying multiple hashes yields incorrect dotted range on nonlinear histories and consecutive selections Mar 20, 2025
@naseschwarz
Copy link
Contributor Author

naseschwarz commented Mar 20, 2025

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 naseschwarz linked a pull request Mar 20, 2025 that will close this issue
4 tasks
@naseschwarz
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants