Sorta OT, but I'm curious, On Sun, Apr 21, 2013 at 12:09 PM, Jonathan Nieder <jrnieder@xxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html