Re: bug? illegal text in commit log

From: René Scharfe <l.s.r@web.de>
Date: Feb 7, 2020, 20:30 UTC
Message-ID: <3cd137fa-b879-9850-0b81-5f907623ee6d@web.de>
In-Reply-To: <xmqqlfpf3qh3.fsf@gitster-ct.c.googlers.com>

Am 07.02.20 um 06:40 schrieb Junio C Hamano:

Show 28 quoted lines

> René Scharfe <l.s.r@web.de> writes:
>
>>>  * the first line that
>>>    - begins with "diff " or "Index", or
>>>    - is "---" (and nothing else on the line)
>>>    signals that the line no longer is part of the log
>>>
>>>  * but if it finds a line that begins with "diff --git" (or
>>>    optionally just "diff "), do not blindly assume that is the end
>>>    of the log, and instead try to find the first "---" line.  If
>>>    there isn't any "---", then take that "diff" line the beginning
>>>    of the patch, but if there is, "---" is the end of the message.
>>>
>>> The latter rule is the new one.  And there is no need to change
>>> format-patch output.
>>
>> I like this idea.  It will probably be tricky to implement, though,
>> as mailinfo currently goes through the input line by line and has no
>> easy way to look ahead.
>>
>> René
>
> Another issue with the approach is that it will be fooled if the
> patch is about removing a line with double-dash and nothing else
> on it.  Unless we can trust the numbers on hunk header lines in the
> "sample patch" embedded in the log message, we cannot reliably tell
> if a line with "---" on it is such a line, or the true end of the
> log message.

Such a patch could be cited in the message as well, with or without a correct hunk header.

Full patches in messages might be rare, lines starting with "diff -" (perhaps talking about a certain diff invocation) or "Index: " (in a language where nouns are capitalized) are probably more likely to occur in the wild.

My problem with the situation is that innocent-looking commits that can be diffed, pushed and pulled suddenly fall apart when used in a mail-based workflow or with rebase am.

Supporting hand-edited messages is especially hard. Git cannot warn the sender, as it's out of the loop.

Bottling the message by adding some kind of header would be watertight, but senders of patch-like messages would need to take care to use a large enough bottle (update the header). Clever rules can cover common cases, but will leak sometimes and might be hard to implement.

René