On Wed, 27 Jan 2010, Sverre Rabbelier wrote: > Heya, > > On Wed, Jan 27, 2010 at 01:45, Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > That wouldn't work either. People can, should, and do add extra things to > > the message before applying it. > > Ah, that's a fair point. FWIW, I do manually edit both incoming and outgoing patches from time to time as well. > > In short, it might make sense to have some anti-corruption logic, but I > > suspect it needs a lot of thought. > > Perhaps it makes sense to make it a separate mode to git am, such that > it only checks that the patch is not corrupted, but does not apply it. > That way it would be possible to download the patch, check that it > arrived unscathed, and then do your usual patch handling. Those who do > not edit patches before applying it would be convenient to set a > configuration option that automatically does it when applying the > patch, either warning about it or aborting (as Juliusz suggested). I think what would be even more useful at first is to find out why corrupted patches still apply. And yet without any changes in the patch format, it should be possible to test the validity of a patch whenever the blob for the preimage SHA1 from the index line in the patch header is available locally. Just applying the patch to that blob and confirming it matches the postimage SHA1 should cover many cases already. Nicolas -- 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