Re: git-am applies commit message diffs

From: Jacob Keller <jacob.keller@gmail.com>
Date: Feb 6, 2026, 08:04 UTC
Message-ID: <CA+P7+xqcBcV8uySGgDfvt2ruAnFmfgaUy6aRbUC2zCzmCgPubw@mail.gmail.com>
In-Reply-To: <bcqvh7ahjjgzpgxwnr4kh3hfkksfruf54refyry3ha7qk7dldf@fij5calmscvm>

On Thu, Feb 5, 2026 at 11:50 PM Matthias Beyer <mail@beyermatthias.de> wrote:

Show 22 quoted lines

>
> Hi,
>
> I am not sure whether this was already reported, searching the lore did
> not yield anything for me, but I might have overlooked it...
>
> This was just posted on mastodon[0]:
>
>     PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
>
>     Like https://
>     github.com/i3/i3/pull/6564 for example
>
>     Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
>
>     This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
>
> TL;DR: If you put a diff in the commit message, that diff will be
> applied by git-am.
>
> This looks clearly like unintended and might be an attack-vector, right?
>

It is certainly surprising. I am not certain I would consider it an attack-vector since you should definitely be reading the commit messages before applying, but I could see the fact that its unintentional is a problem.

I'm surprised patch would apply since it would likely fail due to other non-patch formatted text, no? I suspect this is something that could be handled by using the scissors marker "-- >8 --" in the patch description to indicate the diff is not part of the patch, or perhaps the splitting of the email should somehow indicate this, for example when formatting a patch with a diff in it.

I checked by formatting a patch from my own commit message with an embedded diff, and there is nothing in place to prevent that diff section from being applied. In practice, I think the advice is "don't put diffs in your commit message" or "indent the diff text so that it won't be parsed as a diff hunk by patch or am."

It seems like a good idea to me to improve the format patch output and the git am patch splitting to somehow try and detect the end of a valid commit message and not treat it as a patch content, but I am really uncertain how to go about doing so safely without risking backwards compatibility (modifying format-patch to insert a marker that properly denotes end of commit would cause issues with older versions of git, so we need to use some marker that a well formatted patch already does.

> Best,
> Matthias
>
> [0]: https://mas.to/@zekjur/116022397626943871