public inbox for git@vger.kernel.org
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: Matthias Beyer <mail@beyermatthias.de>
Cc: Jacob Keller <jacob.keller@gmail.com>,
	git@vger.kernel.org, pyokagan@gmail.com
Subject: Re: git-am applies commit message diffs
Date: Fri, 6 Feb 2026 04:03:58 -0500	[thread overview]
Message-ID: <20260206090358.GA2761602@coredump.intra.peff.net> (raw)
In-Reply-To: <hn6q2mdjdqezzvtxfxffmatctnlf4ttvwedfk7wnw7xw75gy4g@hetctv53f7bh>

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

  reply	other threads:[~2026-02-06  9:04 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-06  7:43 git-am applies commit message diffs Matthias Beyer
2026-02-06  8:04 ` Jacob Keller
2026-02-06  8:18   ` Matthias Beyer
2026-02-06  9:03     ` Jeff King [this message]
2026-02-07 14:57       ` [PATCH 0/3] commit-msg.sample: reject messages that would confuse "git am" Phillip Wood
2026-02-07 14:58         ` [PATCH 1/3] templates: add .gitattributes entry for sample hooks Phillip Wood
2026-02-07 14:58         ` [PATCH 2/3] templates: detect commit messages containing diffs Phillip Wood
2026-02-07 14:58         ` [PATCH 3/3] templates: detect messages that contain a separator line Phillip Wood
2026-02-07 21:27           ` Junio C Hamano
2026-02-07 21:38             ` Kristoffer Haugsbakk
2026-02-09  0:17               ` Junio C Hamano
2026-02-09  7:00             ` Jeff King
2026-02-09 10:42               ` Phillip Wood
2026-02-10  6:44                 ` Jeff King
2026-02-09  6:57         ` [PATCH 0/3] commit-msg.sample: reject messages that would confuse "git am" Jeff King
2026-02-09 10:43           ` Phillip Wood
2026-02-09 11:07             ` Matthias Beyer
2026-02-10  6:46             ` Jeff King
2026-02-09 15:58       ` git-am applies commit message diffs Patrick Steinhardt
2026-02-10  2:16         ` Jacob Keller
2026-02-10 14:22           ` Patrick Steinhardt
2026-02-10 15:47             ` Junio C Hamano
2026-02-11  2:31               ` Jacob Keller
2026-02-11  2:34                 ` Jacob Keller
2026-02-11  7:47                   ` Jeff King
2026-02-11 15:23                     ` Kristoffer Haugsbakk
2026-02-11 15:47                     ` Junio C Hamano
2026-02-10  6:56         ` Jeff King
2026-02-13 14:34       ` [PATCH v2 0/2] commit-msg.sample: reject messages that would confuse "git am" Phillip Wood
2026-02-13 14:34         ` [PATCH v2 1/2] templates: add .gitattributes entry for sample hooks Phillip Wood
2026-02-13 14:34         ` [PATCH v2 2/2] templates: detect commit messages containing diffs Phillip Wood
2026-02-13 16:42           ` Kristoffer Haugsbakk
2026-02-13 18:08             ` Junio C Hamano
2026-02-14 14:46             ` Phillip Wood
2026-02-13 17:59           ` Junio C Hamano
2026-02-14 14:36             ` Phillip Wood
2026-02-14 15:42               ` Junio C Hamano
2026-02-13 17:41         ` [PATCH v2 0/2] commit-msg.sample: reject messages that would confuse "git am" Junio C Hamano
2026-02-06  8:59   ` git-am applies commit message diffs Florian Weimer
2026-02-06  9:24     ` Jeff King
2026-02-06  9:48       ` Florian Weimer
2026-02-06 10:08         ` Jeff King
2026-02-06  8:43 ` Kristoffer Haugsbakk
2026-02-06 17:45   ` Jakob Haufe
2026-02-07 10:08     ` Kristoffer Haugsbakk
2026-02-07 21:44 ` Kristoffer Haugsbakk
2026-02-08  0:11 ` [PATCH] doc: add caveat about roundtripping format-patch kristofferhaugsbakk
2026-02-08  1:39   ` Junio C Hamano
2026-02-08 17:18     ` Kristoffer Haugsbakk
2026-02-09 16:42   ` Phillip Wood
2026-02-09 17:59     ` Kristoffer Haugsbakk
2026-02-10 10:57       ` Phillip Wood
2026-02-10 16:00         ` Kristoffer Haugsbakk
2026-02-09 22:37   ` [PATCH v2] " kristofferhaugsbakk
2026-02-09 22:59     ` Junio C Hamano
2026-02-09 23:11       ` Kristoffer Haugsbakk
2026-02-10 11:02     ` Phillip Wood
2026-02-10 18:20     ` Kristoffer Haugsbakk
2026-02-12 22:28     ` [PATCH v3] doc: add caveat about round-tripping format-patch kristofferhaugsbakk
2026-02-12 23:19       ` Junio C Hamano
2026-02-13 14:41         ` Phillip Wood
2026-02-13 14:43           ` Kristoffer Haugsbakk
2026-02-13 18:02           ` Junio C Hamano
2026-02-10  0:53   ` [PATCH] doc: add caveat about roundtripping format-patch Christoph Anton Mitterer
2026-02-10 16:00     ` Kristoffer Haugsbakk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260206090358.GA2761602@coredump.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=jacob.keller@gmail.com \
    --cc=mail@beyermatthias.de \
    --cc=pyokagan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox