Juliusz Chroboczek <Juliusz.Chroboczek@xxxxxxxxxxxxxx> writes: >> Do you have an example of such corrupted and incorrectly applied patches? >> What kind of corruption are you talking about? > > The commit message getting rewrapped. For some reason, the patch itself > was not corrupted. You hopefully check the message (and of course the patch) before applying, so "automatically reject and require force" wouldn't help you much in this case. Either you reject and tell the sender to resend, or you reflow it yourself to save the sender (and yourself) the hassle of round-trip. And if you choose to do the latter, having to force it would actively inconvenience you. > Another case is that of the commit message having its non-ASCII > characters corrupted. I've seen this one. It often is that the commit object records UTF-8, but somehow the MUA didn't mark it as such (or incorrectly marked it as ISO-8859-1), and mailinfo ended up doing unnecessary conversion. When this happens, not just the message but also the patch text is affected. But to use "checksumming" as a solution for this, you need to think about what you checksum. Output from format-patch is "text/plain;charset=UTF-8" and requires 8-bit clean transport, but by cutting and pasting that into MUA you often end up with whatever MIME B/Q-quoting your MUA gives you, and mailinfo is actively unwraps them, so the right place to add an optional check _might_ be immediately after we run mailinfo. At that point, however, the author name and the subject line is in separate records from the body of the commit log message. More realistically, the kind of MUA corruption I personally see most often is "text/plain; format-flowed"; I have a pre-applypatch hook to reject them altogether, but they tend to corrupt leading whitespaces so badly that the patch seldome applies. This is not something "checksumming" is the right tool to solve. One thing that we _might_ consider doing is to reduce the default length of the function name we place on the hunk header line. For some reason, I see they get wrapped in messages I see, even when the proposed commit log message has overlong lines. -- 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