From: Jeff King <peff@peff.net>
Date: Tue, 10 Feb 2026 06:56:13 GMT
Subject: Re: git-am applies commit message diffs
Message-ID: <20260210065613.GC1756549@coredump.intra.peff.net>
In-Reply-To: <aYoEO0CcVt2Qjgnb@pks.im>

On Mon, Feb 09, 2026 at 04:58:51PM +0100, Patrick Steinhardt wrote:

> > 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. ;)
> 
> Maybe we can't parse it unambiguously. But what we _can_ detect is that
> a patch is ambiguous in the first place, right? So maybe we could extend
> git-am(1) to bail by default with a hint that tells the user that:
> 
>   - They ought to double-check the patch.
> 
>   - They can override the check with "--accept-ambiguous-patch".
> 
> It at least notifies the user that something potentially-fishy is going
> on, even though it still shifts the burden onto the person that applies
> the patch. But I guess that cannot ever be avoided anyway, at least in
> the general case.

Yes, I think you could detect ambiguous cases on the receiving side. You
might need some heuristics to reduce false positives, though, since it
is permitted to include extra content between and after diffs (e.g.,
format-patch writes signature lines by default).

So you'd probably need some rules like:

  - Multiple instances of "---" always generate a warning. Though I
    won't be surprised if it turns out that people often do:

       the commit message

       Signed-off-by: etc...
       ---
       Here is some cover letter material.

       ---
         [diffstat goes here]

    That's totally fine, but indistinguishable from the case that the
    commit message contains a "---" and is being truncated.

  - Presence of "diff" header before "---", which means there is
    probably a diff inside the commit message. But then what about when
    there is no "---" at all (as in a non-git patch)? Maybe the rule
    needs to be "there is a --- line after a diff header" or something.

  - Presence of non-empty text lines after a "diff" header (but not at
    the end, which would trigger pointlessly on signature lines). We
    would never generate this with format-patch, but it is historically
    allowed. I sometimes use it when talking through a "something like
    this..." patch. I don't expect those to become real commits, but I
    imagine people do apply them sometimes.

Of course you can sweep all of the false positives under the "well,
you'll have to re-run with --accept-ambiguous-patch" rug. But we would
want to make sure we do not require that often enough to be annoying.

-Peff