"git apply --whitespace=fix" used to be able to assume that fixing errors will always reduce the size by e.g. stripping whitespaces at the end of lines or collapsing runs of spaces into tabs at the beginning of lines. An update to accomodate fixes that lengthens the result by e.g. expanding leading tabs into spaces were made long time ago but the logic miscounted the necessary space after such whitespace fixes, leading to either under-allocation or over-usage of already allocated space. The second patch in this series is to illustrate this with a runtime sanity-check to protect us from future breakage (this is a reroll of a "how about this" weatherbaloon patch $gmane/262579, with Kyle's test script). The third patch corrects the under-counting and makes the new test pass. The fourth patch makes us report the fact that we corrected whitespace errors in the common-context part. When asked to correct whitespace errors, and given a patch that has whitespace errors in the common context (i.e. the lines prefixed with " ") either in the patch itself or the corresponding part in the file we are patching, we have been correcting the whitespace errors "while at it" since around c1beba5b (git-apply --whitespace=fix: fix whitespace fuzz introduced by previous run, 2008-01-30), but we were not reporting that we saw a need to fix them. This is not about the "buffer corruption fix", which is the primary focus of this series, but it is here because it is related to whitespace fix. Junio C Hamano (4): typofix apply: make update_pre_post_images() sanity check the given postlen apply: count the size of postimage correctly apply: detect and mark whitespace errors in context lines when fixing builtin/apply.c | 34 ++++++++++-- t/t4138-apply-ws-expansion.sh | 121 ++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 152 insertions(+), 3 deletions(-) create mode 100755 t/t4138-apply-ws-expansion.sh -- 2.3.0-rc1-116-g84c5016 -- 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