On Tue, Feb 10, 2026 at 6:31 PM Jacob Keller [off-list ref] wrote:

On Tue, Feb 10, 2026 at 7:47 AM Junio C Hamano [off-list ref] wrote:

quoted

Patrick Steinhardt [off-list ref] writes:

quoted

That is worth a thought indeed. I guess one of the biggest questions
here is whether we can introduce such an unambiguous mode in such a way
that old Git clients/patch(1) would continue to understand them. I
wouldn't mind much if they would still misinterpret the ambiguous parts.
But if so, we could make this unambiguous mode the default without a
breaking change.

Yup, if the old versions misinterpret exactly the same way as
before, then it does not even have to be called "unambiguous mode"
that is on by default.  I doubt it is possible, though.

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.