"Dmitry V. Levin" <ldv@xxxxxxxxxxxx> writes: > When checking buffer for NUL byte, do not limit size of buffer we check. > Otherwise we break git-rebase: git-format-patch may generate output which > git-mailinfo cannot handle properly. I think this is tackling a valid problem but it is a wrong solution. The change penalizes text changes which is the majority, just in case there is an unusual change that has an embedded NUL far into the file (iow, exception). Perhaps mailinfo can be updated to handle embedded NUL. Another alternative (I've been trying to find time to do so for quite a while now but dealing with list traffic always takes priority on my time allotment) is to update rebase not to rely on "format-patch piped to am", and I think that is more correct solution in the longer term. In the meantime, a workaround would be to use "rebase -i". It uses cherry-pick machinery instead of "format-patch piped to am", and hopefully would handle NULs better. It probably is slower than non interactive one exactly because it uses cherry-pick, and that is the reason I am first working on updating cherry-pick before actually making the non-interactive rebase to use it. - 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
