On Tue, Feb 10, 2026 at 06:34:05PM -0800, Jacob Keller wrote:

quoted

Hmm. If we add a new unambiguous marker after the ---, old versions
would see '...' and know to cut the description. New versions would
wait for <NEW MARKER> and properly ignore any diff/etc prior to this.

Since <NEW MARKER> is after a ---, it would be ignored and not
inserted as part of the commit message, and because all versions
universally accept cruft between --- and the diff start, this should
be acceptable right?

Keeping in mind we'd have to use <NEW MARKER> as something that we
somehow reject as being a valid part of a commit message somehow, so
that you can't accidentally insert it, and we'd need to be careful
about rejecting formatting such a patch, and probably complaining on
the receiving end if we see multiple markers.. Trickier than it sounds
I imagine.

Yeah, on reading your first message, I wondered if we would run into a
commit message adding "---" followed by the new marker. If the new
marker is forbidden, I guess that works. But how ugly is that new marker
going to be, then? ;) We'll now see it in every email.

If we are going to modify what format-patch produces, I'd be more
inclined to have it perform some reversible quoting on the commit
message so that "---" and "diff" lines are not recognized. And then that
quoting only has to kick in when a message would be ambiguous, so most
people wouldn't even see it.

If an older version of git-am (that does not understand how to unquote
it) receives the mail, the worst case is you'd see the quoting in the
resulting commit message. So if we make it not-too-ugly, that may not be
so bad. Think something along the lines of seeing ">From" in emails. It
is gross and ugly, but you can still read the email.


All that said, if the main goal is just avoiding accidental diffs in
commit messages (and not worrying about truncation due to "---" in
messages), there may be a simpler receiver-side solution. If the
receiver expects the message to be generated by Git, then it will expect
there to be a "---" line. And we will not expect any diff before then.
So could we just have a "git am --strict" mode (and perhaps matching
config option) that always looks for the "---" separator?

It's not foolproof, but I suspect it would help with the worst cases of
embedded diffs. And it's not that hard to implement.

-Peff