From: Jacob Keller Date: Fri, 06 Feb 2026 08:04:54 GMT Subject: Re: git-am applies commit message diffs Message-ID: In-Reply-To: On Thu, Feb 5, 2026 at 11:50 PM Matthias Beyer wrote: > > 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