On Tue, Feb 04, 2020 at 01:25:40PM -0800, Junio C Hamano wrote: > René Scharfe <l.s.r@xxxxxx> 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
