Re: bug? illegal text in commit log

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Feb 04, 2020 at 01:25:40PM -0800, Junio C Hamano wrote:
> René Scharfe <l.s.r@web.de> writes:
> 
> > Am 04.02.20 um 07:14 schrieb Michael S. Tsirkin:
> >> It seems that it's not too hard to make commits such that
> >> the standard way of git format-patch -> email -> git am
> >> fails.
> >
> >> A work around is "don't do it" - avoid putting anything that looks like
> >> a unified diff in the commit log.
> >>
> >> However:
> >> - Users don't know what other restrictions exist
> >> - User sending the patch has no way to detect failure,
> >>   it's only visible to user receiving the patch
> >
> > Putting a diff in a commit message can be useful, and forbidding it is
> > hard to justify.
> >
> >> Ideas:
> >> - validate commit log and warn users?
> >
> > That's only better than the status quo insofar it turns the issue from
> > a hidden pitfall into an open one.
> >
> >> - find a way to escape text in git format-patch, and unescape in git am?
> >
> > Like a Lines: header specifying the number of lines in the commit message?
> 
> I think the existing practice is to indent such a diff in the
> message by a few characters.

So you are for validating commit log and warning users then?

>  And I think that makes sense even
> without counting its value "as a workaround"---we indent materials
> inserted in the message for illustration, and a block of diff is
> just that.

It might be intended for other purposes, for example instructions:

To try out the new foobar flag, execute the following script:

git apply --foobar << EOF
--- a.txt       2020-02-04 01:09:27.927026571 -0500
+++ c.txt       2020-02-04 01:06:57.404688233 -0500
@@ -1 +1 @@
-AA
+BB
EOF

indenting would break the script, and make it harder for users
to follow the instructions.

-- 
MST