fix(gix-object): detect trailers when they are the sole body content#2514
Merged
Sebastian Thiel (Byron) merged 4 commits intoGitoxideLabs:mainfrom Apr 14, 2026
Conversation
Contributor
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ad6948e289
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "Codex (@codex) review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "Codex (@codex) address that feedback".
ad6948e to
da52490
Compare
`BodyRef::from_bytes` searched for `\n\n` *within the body* to find the
trailer block separator. However, `MessageRef::from_bytes` already
consumed the first `\n\n` when splitting the title from the body — so
for a message like:
Fix the thing
Signed-off-by: Alice <alice@example.com>
the body bytes arriving at `BodyRef::from_bytes` are just
`"Signed-off-by: Alice <alice@example.com>"` with no further `\n\n`,
causing zero trailers to be returned and diverging from the behaviour
of `git interpret-trailers --parse`.
Fix: when no `\n\n` is found within the body *and* the first
non-empty line parses as a valid `Token: value` trailer, treat the
entire body as the trailer block (with an empty `body_without_trailer`).
Non-trailer body text followed by a trailer on the same paragraph
(without a blank-line separator) is correctly left unchanged.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
da52490 to
c7908d1
Compare
Also add more tests for more complete compliance with `git interpret-trailers`. Note that the new behaviour is more conforming, which means that trailer blocks must be parseable in full to be be recognised. Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>
Co-authored-by: Sebastian Thiel <sebastian.thiel@icloud.com>
3222835 to
58f7595
Compare
Member
|
Thanks so much to get this started! I ended up having Codex implement a compliant version of this, along with support for continuations/multi-line (those are folded into a single line). |
2 tasks
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.
Problem
BodyRef::from_bytessearched for\n\nwithin the body to find the trailer block. ButMessageRef::from_bytesalready consumed the first\n\nwhen splitting the title from the body — so for a message like:the body bytes arriving at
BodyRef::from_bytesare just"Signed-off-by: Alice <alice@example.com>"with no inner\n\n. The result was zero trailers, diverging fromgit interpret-trailers --parse:This is the common case in practice: a subject line followed directly by trailers with no other body text (Gerrit
Change-Id, GitHubCo-authored-by, etc.).Fix
When no
\n\nis found within the body and the first non-empty line parses as a validToken: valuetrailer, treat the entire body as the trailer block (with an emptybody_without_trailer). Non-trailer body text followed by a trailer on the same paragraph without a blank-line separator is correctly left unchanged — a blank line is still required to delimit the trailer block from preceding prose.Tests added
trailer_as_sole_body_content— single trailer, no preceding body textmultiple_trailers_as_sole_body_content— multiple trailers, no preceding body textbody_text_then_trailer_without_blank_line_is_not_a_trailer— guard: body text + trailer in same paragraph (no\n\n) is not a trailer blocktrailer_as_sole_body_content_via_message_ref— end-to-end through the publicMessageRefAPI🤖 Generated with Claude Code