Re: git-am applies commit message diffs

From: Kristoffer Haugsbakk <kristofferhaugsbakk@fastmail.com>
Date: Feb 7, 2026, 10:08 UTC
Message-ID: <f6e4cdb4-ff82-4853-aca5-0c152f287286@app.fastmail.com>
In-Reply-To: <20260206184508.5a014df2@beer>

On Fri, Feb 6, 2026, at 18:45, Jakob Haufe wrote:

Show 17 quoted lines

> On Fri, 06 Feb 2026 09:43:04 +0100
> "Kristoffer Haugsbakk" <kristofferhaugsbakk@fastmail.com> wrote:
>
>> Like Jacob said the cure is to use indentation for code blocks.
>
> That doesn't help here as stated by Michael on GH and his Mastodon
> post. Also, to make sure this doesn't get lost:
>
> From patch(1):
>
> ---
> If the entire diff is indented by a consistent amount, if lines end in CRLF,
> or if a diff is encapsulated one or more times by prepending "- " to lines
> starting with "-" as specified by Internet RFC 934, this is taken into account.
> After removing indenting or encapsulation, lines beginning with # are ignored,
> as they are considered to be comments.
> ---

Yeah, I think I understand now.

• patch(1) will apply all the diffs from git-format-patch(1), including
  from the commit message
• git-am(1) will do the same
• git-am(1) will do the expected thing if you indent the diff in the
  commit message
• For the git-format-patch(1) output with an indented diff in the commit
  message: `git patch -p1` (I guess to strip the `a/` and `b/` from
  git(1) diffs?) applies everything, including the `sleep(1)`[1]

My hodgepodge assumptions from 2024[2] were off. I thought that as long as you did the following:

• Do not put the magic `From` string at the start of any line in the
  commit message
• Do not put `---` at the start of the line in the commit message
• Do not put diff output unindented in the commit message since
  git-am(1) will think that is the diff and not care about finding any
  `–––`[3]

Then git-am(1) would apply the commit message and the diff part as expected.

† 1: Related is https://github.com/i3/i3/pull/6564#issuecomment-3863278059 ,
     specifically the link https://lists.gnu.org/archive/html/bug-patch/2026-02/msg00000.html
[2]: https://lore.kernel.org/git/ca13705ae4817ffba16f97530637411b59c9eb19.camel@scientia.org/
† 3: And my assumption here that only the diff in the commit message
     would be applied in this case was wrong. Or else it would have been
     more immediately obvious that the resulting commit was wrong.

> It's not exactly written in a straightforward way,

Yeah it’s not straightforward at all.

Something useful might be to apply all patches if they are all at the same indentation level. I don’t see how it is useful to apparently strip all indentation and find all the diffs that way.

> but it show that the behavior from patch is intentional. So even if
> git-am gets a fix, it only partly mitigates the problem as I'm pretty
> sure I will not be the last one to pass "git show"/"git format-patch"
> to "patch".

I don’t pass output from git(1) to patch(1). But I have often (like the handful of times I’ve needed it) fallen back on using patch(1) for patches/diffs that are thrown into email messages since it is more forgiving than git-apply(1), and I guess also git-am(1).

The diff in the commit message doesn’t have the trailing whitespace that I thought would be needed for patch application. Since git-commit(1) by default cleans up trailing whitespace. But apparently patch(1) is fine with that.