git-am(1) (apply patches) delimits the commit message from the patch/diff by looking for (1) a line `---` or (2) a line that starts with `diff -` or (3) a line that starts with `Index:SP` (SP is space). Only the first rule is necessary for patches generated git-format-patch(1). But git-am(1) is for applying patches, and you are free to bring patches from some other system. That’s why, I suppose, there are multiple options.

This means that it will try to apply any unindented diffs in the commit message. But you’re fine if you indent the diff. (Newschool code fencers will have a worse time here.)

I imagine that this worked fine for changes that were authored by one person and submitted by another person via email, or by their friend, or by someone trying to resurrect a previous attempt at getting something upstreamed. Someone is likely to notice that examples diffs are getting applied. But it won’t work well at all if you are some software distributor who is using patch files to apply modifications to packages.

Recall that git-am(1) will not apply indented diffs. Well have a look at my GNU patch 2.7.6:

    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.

Some may say that patch(1) should work like a more straightforward importer. But I’ve been itching to point out something else.

    Larry Wall wrote the original version of patch.

Is it surprising if patch(1) is a bit DWIM?