Re: git-am applies commit message diffs
- From
Jacob Keller <jacob.keller@gmail.com>
- Date
- Feb 11, 2026, 02:31 UTC
- 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:
Show 14 quoted lines
> > 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?