fix: preserve line order when staging non-contiguous lines in change blocks #5120
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes a bug in patch transformation where staging non-contiguous lines within change blocks (multiple consecutive deletions followed by additions) would not preserve the correct line order. The fix introduces special handling for change blocks to ensure that selected deletions and additions are kept together as pairs, while unselected deletions are converted to context lines.
Key Changes:
- Added logic to detect and handle change blocks (multiple consecutive deletions) as a unit
- Selected deletions and additions are now processed together before appending unselected lines as context
- New test case validates that non-contiguous selection preserves change pair relationships
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| pkg/commands/patch/transform.go | Implemented change block detection and special handling for non-contiguous line selection in the transformHunkLines function |
| pkg/commands/patch/patch_test.go | Added test case TestTransformNonContiguousSelection to verify correct behavior when selecting non-contiguous lines in change blocks |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
modified: pkg/commands/patch/patch_test.go modified: pkg/commands/patch/transform.go
elskow
force-pushed
the
fix/5103-staging-line-order
branch
from
4a79153 to
3549de8
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
@stefanhaller mind taking a look? |
|
@elskow Sorry for the long delay. This would be a very welcome fix if it worked. However, it doesn't seem to. I didn't look at the code very much yet, I just tried the feature, and here's what I found: I'm starting with a file containing and then making these changes: Now I'm trying to stage just the "2 -> 2a" change, and I end up with these staged changes: This is with either master or your branch, so this doesn't seem to be fixed. Also, when staging all lines and then trying to unstage either of the deleted lines, I get a "patch does not apply" error. I stopped testing at that point. From a very cursory look at the code, it seems that you are trying to do something similar to what git gui does to solve this. And I'm not convinced that this is the best approach: git gui's approach is a tradeoff that makes the more common use cases work (which is good), at the expense of breaking less common use cases (unstaging lines). Here's a comment from git-gui's code that explains this. I have the feeling that it should be possible to do better, solving all cases correctly, by looking not just at the patch itself, but also at the patch of what's already staged, and then adjusting hunk line numbers accordingly. This is a very vague idea, I haven't thought it through. |
2 participants
Fixes #5103
When you have a diff with consecutive deletions followed by additions (like renaming a variable across multiple lines), and you try to stage only some of them (e.g., first deletion + first addition), the resulting patch had lines in the wrong order.
The problem was that unselected deletions were being converted to context lines immediately, causing them to appear between the selected deletion and addition. Now we defer those context lines until after all additions in the block.
Before:
After: