Re: git log -p unexpected behaviour - security risk?

Sorta OT, but I'm curious,

On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder [off-list ref] wrote:

For example, whenever git adds (or plans) support for a new header
line in commit objects, before you've upgraded, a prankster can
provide a bad value for that header line in objects they hand-craft.
"git fsck" in your older version of git will accept the resulting
objects on the assumption that they came from a newer version of git,
so you won't notice.  Later you upgrade Git and "git fsck" considers
the objects malformed.  Clients with "[transfer] fsckobjects" enabled
start to reject your history.  That is, this person has made your
repository corrupt in the eyes of "git fsck".

The usual excellent integrity checking will let you pinpoint the
problem to the merge from that untrusted person so you can avoid
trusting them again, and all the data will be there to recover without
them.  So it is auditable later.  But this does mean that with the
current design, there is some level of trust required to let someone
commit into your history unless you inspect their work with a
fine-toothed comb.

Has anyone written a test case for this?