Subject: Re: git-am applies commit message diffs

From: Jeff King <[email-masked]>
Date: Fri, 6 Feb 2026 04:03:58 -0500

On Fri, Feb 06, 2026 at 09:18:50AM +0100, Matthias Beyer wrote:

> That said, I am no expert in either C or the git codebase at all, but
> from what I saw from reading the git-am codebase, it looks like it tries
> to find the patch by looking for three dashes on a line with a linebreak
> behind ("---\n").

Yes, that is how the split is made.

> From what I read, it looks for that from the first line.
> What I would think of here is looking for that "patchbreak" from the
> _end_ of the email rather than from the top, that would have prevented
> this issue, right?

The patch itself may legitimately contain "---" on a line by itself (it
would indicate that the line "--" was removed from a file). That would
confuse your parser, including in a way that we end up only applying
part of the diff (everything before that fake "---" becomes commit
message, and everything after becomes cover-letter material up to the
next "diff" line).

I suspect it also creates corner cases with cover-letter material
(between the "---" and the diff itself) that itself contains any "---"
marker.

I don't think there is a way to unambiguously parse the single-stream
output that format-patch produces. This is a reasonably well-known
gotcha (at least around here). E.g., some earlier discussions:

  2024: https://lore.kernel.org/git/[email-masked]/
  2022: https://lore.kernel.org/git/d0b5778251[email-masked]/
  2015: https://lore.kernel.org/git/CAFOYHZC6Qd9wkoWPcTJDxAs9u=[email-masked]/

There are probably more, but it's actually a tricky thing to search for
in the archive, so I stopped digging. ;)

I think the general attitude has been that such things are a nuisance
when you trigger them accidentally, but probably an unlikely security
issue if we assume a human is reading the patch (and if they're not, all
bets are off anyway).

Ironically, you can ask format-patch to split the message and patch
using the "--attach" option, which should be unambiguous (they are in
two mime parts). But git-mailinfo (which powers git-am under the hood)
decodes the two parts into a single stream, and still takes a "diff"
line in the commit message part as the start of the diff.

Arguably that could be improved, but I suspect might break other cases
(I think it is trying to be forgiving to folks who have shoved the whole
patch into an attachment). So you'd have to pull the attachments apart
yourself and feed them individually to "git apply" and "git commit -F".

-Peff