merge: keep conflict markers on their own lines when hunks lack a trailing newline#85
Open
jochenhz wants to merge 1 commit into
Open
merge: keep conflict markers on their own lines when hunks lack a trailing newline#85jochenhz wants to merge 1 commit into
jochenhz wants to merge 1 commit into
Conversation
A conflicting hunk at end-of-file without a trailing newline glued the next marker onto its last content line, producing unparseable output. Matches git merge-file --diff3 behavior. Signed-off-by: Jochen Hunz <j.hunz@anchorpoint.app>
jochenhz
added a commit
to Anchorpoint-Software/lore
that referenced
this pull request
Jul 18, 2026
Vendor diffy 0.4.2 with a newline guard in both conflict-marker builders until a release contains the upstream fix (bmwill/diffy#85). Signed-off-by: Jochen Hunz <j.hunz@anchorpoint.app>
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.
When a conflicting hunk sits at end-of-file without a trailing newline,
merge/merge_bytesglue the next conflict marker onto the content line, producing unparseable output:
Actual:
Expected (matches
git merge-file --diff3on identical inputs):add_conflict_marker/add_conflict_marker_bytesnow prefix a newline when the outputdoesn't already end with one. Only reachable for file-final hunks, so all existing merge
output is unchanged — the full suite passes untouched. One new test covers both the str
and bytes paths via
assert_merge!.