From: Jeff King Date: Fri, 06 Feb 2026 09:03:58 GMT Subject: Re: git-am applies commit message diffs Message-ID: <20260206090358.GA2761602@coredump.intra.peff.net> In-Reply-To: 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/ca13705ae4817ffba16f97530637411b59c9eb19.camel@scientia.org/ 2022: https://lore.kernel.org/git/d0b577825124ac684ab304d3a1395f3d2d0708e8.1662333027.git.matheus.bernardino@usp.br/ 2015: https://lore.kernel.org/git/CAFOYHZC6Qd9wkoWPcTJDxAs9u=FGpHQTkjE-guhwkya0DRVA6g@mail.gmail.com/ 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