Repository navigation
Fix absorb refusing any change that deletes lines - #60
Merged
Merged
Conversation
Absorbing a staged change that only removed lines always failed: the dry run planned it fine, then the real run refused with "could not be applied ... this is a bug in stack_absorb" and git apply's output saying a hunk succeeded at an offset of 1 line. A migration with a couple of deleted lines among nine other hunks was enough to hit it. The patches absorb writes number each hunk the way git diff -U0 does, and for a deletion git diff gives the line before the gap. git apply doesn't read it that way though; it takes the new start as the line where the removed lines begin, so it found them one line further down and said so. We refuse any apply at an offset (a hunk landing somewhere other than where the plan put it would be silently wrong), so every deletion was turned away even though the plan was right. So the patch now gives a deletion the line its removed lines start on, once the hunks above it are in, and git apply places it exactly where it says. The offset check stays as it was, so a hunk that really doesn't fit where it was planned is still refused.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Absorbing a staged change that only removed lines always failed. The dry run planned it fine, then the real run refused with "could not be applied ... this is a bug in stack_absorb", and git apply's output said a hunk succeeded at an offset of 1 line. This came up for real on a migration where a couple of the eleven hunks were deletions.
The patches absorb writes number each hunk the way
git diff -U0does, and for a deletion git diff gives the line before the gap. git apply doesn't read it that way though: it takes the new start as the line where the removed lines begin, so it found them one line further down and said so. We refuse any apply at an offset (a hunk landing somewhere other than where the plan put it would be silently wrong), so every deletion was turned away even though the plan was right. I checked this against git apply directly with a one line deletion: numbered the git diff way it applies "at offset 1 line", numbered from the first removed line it applies exactly.So a deletion's new start is now the line its removed lines start on, once the hunks above it are in. The offset check is unchanged, so a hunk that really doesn't fit where it was planned is still refused.