From: Jacob Keller <jacob.keller@gmail.com>
Date: Wed, 11 Feb 2026 02:31:23 GMT
Subject: Re: git-am applies commit message diffs
Message-ID: <CA+P7+xo0-9h_V8xGQaEdgBEaxjrbrNOdPfmFmhKup+Z-7w0zUw@mail.gmail.com>
In-Reply-To: <xmqq34381tze.fsf@gitster.g>

On Tue, Feb 10, 2026 at 7:47 AM Junio C Hamano <gitster@pobox.com> wrote:
>
> Patrick Steinhardt <ps@pks.im> writes:
>
> > 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?