{"thread":{"id":"20264","subject":"[PATCHv3] git apply: option to ignore whitespace differences","startedAt":"2009-07-28T21:00:20Z","lastAt":"2009-07-31T19:22:09Z","messageCount":15,"participants":["Giuseppe Bilotta","Junio C Hamano","Nanako Shiraishi","Felipe Contreras"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"118984","messageId":"1248814820-25367-1-git-send-email-giuseppe.bilotta@gmail.com","threadId":"20264","inReplyTo":null,"subject":"[PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-28T21:00:20Z","receivedAt":"2009-07-28T21:00:20Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"Introduce --ignore-whitespace option and corresponding config bool to\nignore whitespace differences while applying patches, akin to the\n'patch' program.\n\n'git am', 'git rebase' and the bash git completion are made aware of\nthis option.\n\nSigned-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>\n---\n\nThird iteration of the ignore-whitespace option for git-apply. Sorry for\nthe long delay from the previous one, but I've been busy with real-life\nstuff.\n\nSignificant changes since the previous iterations:\n* a boolean config option has been introduced\n* the patch that synchronized the whitespace when it was being ignored\n  has been squashed in\n* the fuzzy buffer comparison needs the length of both buffers since, as\n  pointed out in a private comunication, the hash check is not enough to\n  guarantee that the candidates have the same non-whitespace characters\n\nWith regard to this, by the way, the expected failure for patch3 is\ncurrently catched by a hashing, but it should be improved by generating\ntwo lines with the same hash, one being a proper initial substring of\nthe other (modulo whitespace); a situation which I wasn't able to create\nwithout resorting to situations that would make git (and diff) go\nbinary. Suggestions welcome.\n\nAlso, I've come across the need to implement a similar option for merges\n(which basically reduces to adding the flag XDF_IGNORE_WHITESPACE_CHANGE\nin appropriate places) but couldn't come up with a sensible way to\nexpose it via parameters to pass through to the merge engines, whose\ninteractions are a little over my head for now.\n\n\n Documentation/config.txt               |    5 +\n Documentation/git-am.txt               |    3 +-\n Documentation/git-apply.txt            |    7 ++\n Documentation/git-rebase.txt           |    3 +-\n builtin-apply.c                        |  135 ++++++++++++++++++++++++++++--\n contrib/completion/git-completion.bash |    3 +\n git-am.sh                              |    3 +-\n git-rebase.sh                          |    3 +\n t/t4107-apply-ignore-whitespace.sh     |  143 ++++++++++++++++++++++++++++++++\n 9 files changed, 295 insertions(+), 10 deletions(-)\n create mode 100755 t/t4107-apply-ignore-whitespace.sh\n\ndiff --git a/Documentation/config.txt b/Documentation/config.txt\nindex 792dd42..c24fa5d 100644\n--- a/Documentation/config.txt\n+++ b/Documentation/config.txt\n@@ -461,6 +461,11 @@ it will be treated as a shell command.  For example, defining\n executed from the top-level directory of a repository, which may\n not necessarily be the current directory.\n \n+apply.ignore-whitespace::\n+\tTells 'git-apply' to ignore whitespaces differences,\n+\tin the same way as the '--ignore-whitespace' option.\n+\tSee linkgit:git-apply[1].\n+\n apply.whitespace::\n \tTells 'git-apply' how to handle whitespaces, in the same way\n \tas the '--whitespace' option. See linkgit:git-apply[1].\ndiff --git a/Documentation/git-am.txt b/Documentation/git-am.txt\nindex 32e689b..acd2a5d 100644\n--- a/Documentation/git-am.txt\n+++ b/Documentation/git-am.txt\n@@ -11,7 +11,7 @@ SYNOPSIS\n [verse]\n 'git am' [--signoff] [--keep] [--utf8 | --no-utf8]\n \t [--3way] [--interactive] [--committer-date-is-author-date]\n-\t [--ignore-date]\n+\t [--ignore-date] [--ignore-whitespace]\n \t [--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]\n \t [--reject] [-q | --quiet]\n \t [<mbox> | <Maildir>...]\n@@ -65,6 +65,7 @@ default.   You can use `--no-utf8` to override this.\n \tit is supposed to apply to and we have those blobs\n \tavailable locally.\n \n+--ignore-date::\n --whitespace=<option>::\n -C<n>::\n -p<n>::\ndiff --git a/Documentation/git-apply.txt b/Documentation/git-apply.txt\nindex 735374d..ef92c03 100644\n--- a/Documentation/git-apply.txt\n+++ b/Documentation/git-apply.txt\n@@ -13,6 +13,7 @@ SYNOPSIS\n \t  [--apply] [--no-add] [--build-fake-ancestor=<file>] [-R | --reverse]\n \t  [--allow-binary-replacement | --binary] [--reject] [-z]\n \t  [-pNUM] [-CNUM] [--inaccurate-eof] [--recount] [--cached]\n+\t  [--ignore-whitespace]\n \t  [--whitespace=<nowarn|warn|fix|error|error-all>]\n \t  [--exclude=PATH] [--include=PATH] [--directory=<root>]\n \t  [--verbose] [<patch>...]\n@@ -149,6 +150,9 @@ patch to each path is used.  A patch to a path that does not match any\n include/exclude pattern is used by default if there is no include pattern\n on the command line, and ignored if there is any include pattern.\n \n+--ignore-whitespace::\n+\tWhen applying a patch, ignore whitespace differences if necessary.\n+\n --whitespace=<action>::\n \tWhen applying a patch, detect a new or modified line that has\n \twhitespace errors.  What are considered whitespace errors is\n@@ -205,6 +209,9 @@ running `git apply --directory=modules/git-gui`.\n Configuration\n -------------\n \n+apply.ignore-whitespace::\n+\tSet this boolean configuration flag if you want to ignore whitespace\n+\tdifferences to be ignored by default.\n apply.whitespace::\n \tWhen no `--whitespace` flag is given from the command\n \tline, this configuration item is used as the default.\ndiff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt\nindex db1b71d..0aefc34 100644\n--- a/Documentation/git-rebase.txt\n+++ b/Documentation/git-rebase.txt\n@@ -268,8 +268,9 @@ OPTIONS\n \texit with the message \"Current branch is up to date\" in such a\n \tsituation.\n \n+--ignore-whitespace::\n --whitespace=<option>::\n-\tThis flag is passed to the 'git-apply' program\n+\tThese flag are passed to the 'git-apply' program\n \t(see linkgit:git-apply[1]) that applies the patch.\n \tIncompatible with the --interactive option.\n \ndiff --git a/builtin-apply.c b/builtin-apply.c\nindex 39dc96a..792c7ac 100644\n--- a/builtin-apply.c\n+++ b/builtin-apply.c\n@@ -39,6 +39,7 @@ static int diffstat;\n static int numstat;\n static int summary;\n static int check;\n+static int ignore_whitespace;\n static int apply = 1;\n static int apply_in_reverse;\n static int apply_with_reject;\n@@ -214,6 +215,62 @@ static uint32_t hash_line(const char *cp, size_t len)\n \treturn h;\n }\n \n+/*\n+ * Compare lines s1 of length n1 and s2 of length n2, ignoring\n+ * whitespace difference. Returns 1 if they match, 0 otherwise\n+ */\n+static int fuzzy_matchlines(const char *s1, size_t n1,\n+\t\t\t    const char *s2, size_t n2)\n+{\n+\tconst char *last1 = s1 + n1 - 1;\n+\tconst char *last2 = s2 + n2 - 1;\n+\tint result = 0;\n+\n+\tif (n1 < 0 || n2 < 0)\n+\t\treturn 0;\n+\n+\t/* ignore line endings */\n+\twhile ((*last1 == '\\r') || (*last1 == '\\n'))\n+\t\tlast1--;\n+\twhile ((*last2 == '\\r') || (*last2 == '\\n'))\n+\t\tlast2--;\n+\n+\t/* skip leading whitespace */\n+\twhile (isspace(*s1) && (s1 <= last1))\n+\t\ts1++;\n+\twhile (isspace(*s2) && (s2 <= last2))\n+\t\ts2++;\n+\t/* early return if both lines are empty */\n+\tif ((s1 > last1) && (s2 > last2))\n+\t\treturn 1;\n+\twhile (!result) {\n+\t\tresult = *s1++ - *s2++;\n+\t\t/*\n+\t\t * Skip whitespace inside. We check for whitespace on\n+\t\t * both buffers because we don't want \"a b\" to match\n+\t\t * \"ab\"\n+\t\t */\n+\t\tif (isspace(*s1) && isspace(*s2)) {\n+\t\t\twhile (isspace(*s1) && s1 <= last1)\n+\t\t\t\ts1++;\n+\t\t\twhile (isspace(*s2) && s2 <= last2)\n+\t\t\t\ts2++;\n+\t\t}\n+\t\t/*\n+\t\t * If we reached the end on one side only,\n+\t\t * lines don't match\n+\t\t */\n+\t\tif (\n+\t\t    ((s2 > last2) && (s1 <= last1)) ||\n+\t\t    ((s1 > last1) && (s2 <= last2)))\n+\t\t\treturn 0;\n+\t\tif ((s1 > last1) && (s2 > last2))\n+\t\t\tbreak;\n+\t}\n+\n+\treturn !result;\n+}\n+\n static void add_line_info(struct image *img, const char *bol, size_t len, unsigned flag)\n {\n \tALLOC_GROW(img->line_allocated, img->nr + 1, img->alloc);\n@@ -1672,10 +1729,17 @@ static int read_old_data(struct stat *st, const char *path, struct strbuf *buf)\n \t}\n }\n \n+/*\n+ * Update the preimage, and the common lines in postimage,\n+ * from buffer buf of length len. If postlen is 0 the postimage\n+ * is updated in place, otherwise it's updated on a new buffer\n+ * of length postlen\n+ */\n+\n static void update_pre_post_images(struct image *preimage,\n \t\t\t\t   struct image *postimage,\n \t\t\t\t   char *buf,\n-\t\t\t\t   size_t len)\n+\t\t\t\t   size_t len, size_t postlen)\n {\n \tint i, ctx;\n \tchar *new, *old, *fixed;\n@@ -1694,11 +1758,19 @@ static void update_pre_post_images(struct image *preimage,\n \t*preimage = fixed_preimage;\n \n \t/*\n-\t * Adjust the common context lines in postimage, in place.\n-\t * This is possible because whitespace fixing does not make\n-\t * the string grow.\n+\t * Adjust the common context lines in postimage. This can be\n+\t * done in-place when we are just doing whitespace fixing,\n+\t * which does not make the string grow, but needs a new buffer\n+\t * when ignore_whitespace causes the update, since in this case\n+\t * we could have e.g. tabs converted to multiple spaces.\n+\t * We trust the caller to tell us if the update can be done\n+\t * in place (postlen==0) or not.\n \t */\n-\tnew = old = postimage->buf;\n+\told = postimage->buf;\n+\tif (postlen)\n+\t\tnew = postimage->buf = xmalloc(postlen);\n+\telse\n+\t\tnew = old;\n \tfixed = preimage->buf;\n \tfor (i = ctx = 0; i < postimage->nr; i++) {\n \t\tsize_t len = postimage->line[i].len;\n@@ -1773,12 +1845,57 @@ static int match_fragment(struct image *img,\n \t    !memcmp(img->buf + try, preimage->buf, preimage->len))\n \t\treturn 1;\n \n+\t/*\n+\t * No exact match. If we are ignoring whitespace, run a line-by-line\n+\t * fuzzy matching. We collect all the line length information because\n+\t * we need it to adjust whitespace if we match.\n+\t */\n+\tif (ignore_whitespace) {\n+\t\tsize_t imgoff = 0;\n+\t\tsize_t preoff = 0;\n+\t\tsize_t postlen = postimage->len;\n+\t\tsize_t imglen[preimage->nr];\n+\t\tfor (i = 0; i < preimage->nr; i++) {\n+\t\t\timglen[i] = img->line[try_lno+i].len;\n+\t\t\tsize_t prelen = preimage->line[i].len;\n+\t\t\tif (!fuzzy_matchlines(\n+\t\t\t\timg->buf + try + imgoff, imglen[i],\n+\t\t\t\tpreimage->buf + preoff, prelen))\n+\t\t\t\treturn 0;\n+\t\t\tif (preimage->line[i].flag & LINE_COMMON)\n+\t\t\t\tpostlen += imglen[i] - prelen;\n+\t\t\timgoff += imglen[i];\n+\t\t\tpreoff += prelen;\n+\t\t}\n+\n+\t\t/*\n+\t\t * Ok, the preimage matches with whitespace fuzz. Update it and\n+\t\t * the common postimage lines to use the same whitespace as the\n+\t\t * target. imgoff now holds the true length of the target that\n+\t\t * matches the preimage, and we need to update the line lengths\n+\t\t * of the preimage to match the target ones.\n+\t\t */\n+\t\tfixed_buf = xmalloc(imgoff);\n+\t\tmemcpy(fixed_buf, img->buf + try, imgoff);\n+\t\tfor (i = 0; i < preimage->nr; i++)\n+\t\t\tpreimage->line[i].len = imglen[i];\n+\n+\t\t/*\n+\t\t * Update the preimage buffer and the postimage context lines.\n+\t\t */\n+\t\tupdate_pre_post_images(preimage, postimage,\n+\t\t\t\tfixed_buf, imgoff, postlen);\n+\t\treturn 1;\n+\t}\n+\n \tif (ws_error_action != correct_ws_error)\n \t\treturn 0;\n \n \t/*\n \t * The hunk does not apply byte-by-byte, but the hash says\n-\t * it might with whitespace fuzz.\n+\t * it might with whitespace fuzz. We haven't been asked to\n+\t * ignore whitespace, we were asked to correct whitespace\n+\t * errors, so let's try matching after whitespace correction.\n \t */\n \tfixed_buf = xmalloc(preimage->len + 1);\n \tbuf = fixed_buf;\n@@ -1830,7 +1947,7 @@ static int match_fragment(struct image *img,\n \t * hunk match.  Update the context lines in the postimage.\n \t */\n \tupdate_pre_post_images(preimage, postimage,\n-\t\t\t       fixed_buf, buf - fixed_buf);\n+\t\t\t       fixed_buf, buf - fixed_buf, 0);\n \treturn 1;\n \n  unmatch_exit:\n@@ -3272,6 +3389,8 @@ static int git_apply_config(const char *var, const char *value, void *cb)\n {\n \tif (!strcmp(var, \"apply.whitespace\"))\n \t\treturn git_config_string(&apply_default_whitespace, var, value);\n+\telse if (!strcmp(var, \"apply.ignore-whitespace\"))\n+\t\tignore_whitespace = git_config_bool(var, value);\n \treturn git_default_config(var, value, cb);\n }\n \n@@ -3384,6 +3503,8 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)\n \t\t{ OPTION_CALLBACK, 0, \"whitespace\", &whitespace_option, \"action\",\n \t\t\t\"detect new or modified lines that have whitespace errors\",\n \t\t\t0, option_parse_whitespace },\n+\t\tOPT_BOOLEAN(0, \"ignore-whitespace\", &ignore_whitespace,\n+\t\t\t\"ignore whitespace differences when finding context\"),\n \t\tOPT_BOOLEAN('R', \"reverse\", &apply_in_reverse,\n \t\t\t\"apply the patch in reverse\"),\n \t\tOPT_BOOLEAN(0, \"unidiff-zero\", &unidiff_zero,\ndiff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash\nindex 5543dc4..7978d1d 100755\n--- a/contrib/completion/git-completion.bash\n+++ b/contrib/completion/git-completion.bash\n@@ -674,6 +674,7 @@ _git_am ()\n \t--*)\n \t\t__gitcomp \"\n \t\t\t--3way --committer-date-is-author-date --ignore-date\n+\t\t\t--ignore-whitespace\n \t\t\t--interactive --keep --no-utf8 --signoff --utf8\n \t\t\t--whitespace=\n \t\t\t\"\n@@ -695,6 +696,7 @@ _git_apply ()\n \t\t\t--stat --numstat --summary --check --index\n \t\t\t--cached --index-info --reverse --reject --unidiff-zero\n \t\t\t--apply --no-add --exclude=\n+\t\t\t--ignore-whitespace\n \t\t\t--whitespace= --inaccurate-eof --verbose\n \t\t\t\"\n \t\treturn\n@@ -1537,6 +1539,7 @@ _git_config ()\n \t__gitcomp \"\n \t\tadd.ignore-errors\n \t\talias.\n+\t\tapply.ignore-whitespace\n \t\tapply.whitespace\n \t\tbranch.autosetupmerge\n \t\tbranch.autosetuprebase\ndiff --git a/git-am.sh b/git-am.sh\nindex d64d997..fe024b1 100755\n--- a/git-am.sh\n+++ b/git-am.sh\n@@ -16,6 +16,7 @@ s,signoff       add a Signed-off-by line to the commit message\n u,utf8          recode into utf8 (default)\n k,keep          pass -k flag to git-mailinfo\n whitespace=     pass it through git-apply\n+ignore-whitespace pass it through git-apply\n directory=      pass it through git-apply\n C=              pass it through git-apply\n p=              pass it through git-apply\n@@ -303,7 +304,7 @@ do\n \t\tgit_apply_opt=\"$git_apply_opt $(sq \"$1$2\")\"; shift ;;\n \t--patch-format)\n \t\tshift ; patch_format=\"$1\" ;;\n-\t--reject)\n+\t--reject|--ignore-whitespace)\n \t\tgit_apply_opt=\"$git_apply_opt $1\" ;;\n \t--committer-date-is-author-date)\n \t\tcommitter_date_is_author_date=t ;;\ndiff --git a/git-rebase.sh b/git-rebase.sh\nindex 18bc694..d741752 100755\n--- a/git-rebase.sh\n+++ b/git-rebase.sh\n@@ -333,6 +333,9 @@ do\n \t\t\t;;\n \t\tesac\n \t\t;;\n+\t--ignore-whitespace)\n+\t\tgit_am_opt=\"$git_am_opt $1\"\n+\t\t;;\n \t--committer-date-is-author-date|--ignore-date)\n \t\tgit_am_opt=\"$git_am_opt $1\"\n \t\tforce_rebase=t\ndiff --git a/t/t4107-apply-ignore-whitespace.sh b/t/t4107-apply-ignore-whitespace.sh\nnew file mode 100755\nindex 0000000..5a09001\n--- /dev/null\n+++ b/t/t4107-apply-ignore-whitespace.sh\n@@ -0,0 +1,143 @@\n+#!/bin/sh\n+#\n+# Copyright (c) 2009 Giuseppe Bilotta\n+# Copyright (c) 2005 Junio C Hamano\n+# Copyright (c) 2005 Robert Fitzsimons\n+#\n+\n+test_description='git-apply --ignore-whitespace.\n+\n+'\n+. ./test-lib.sh\n+\n+# setup\n+\n+cat > patch1.patch <<\\EOF\n+diff --git a/main.c b/main.c\n+new file mode 100644\n+--- /dev/null\n++++ b/main.c\n+@@ -0,0 +1,22 @@\n++#include <stdio.h>\n++\n++void print_int(int num);\n++int func(int num);\n++\n++int main() {\n++       int i;\n++\n++       for (i = 0; i < 10; i++) {\n++               print_int(func(i)); /* stuff */\n++       }\n++\n++       return 0;\n++}\n++\n++int func(int num) {\n++       return num * num;\n++}\n++\n++void print_int(int num) {\n++       printf(\"%d\", num);\n++}\n+EOF\n+cat > patch2.patch <<\\EOF\n+diff --git a/main.c b/main.c\n+--- a/main.c\n++++ b/main.c\n+@@ -10,6 +10,8 @@\n+ \t\tprint_int(func(i)); /* stuff */\n+ \t}\n+ \n++\tprintf(\"\\n\");\n++\n+ \treturn 0;\n+ }\n+ \n+EOF\n+\n+cat > patch3.patch <<\\EOF\n+diff --git a/main.c b/main.c\n+--- a/main.c\n++++ b/main.c\n+@@ -10,1 +10,1 @@\n+ \t\tprint_int(func(i)); \n+EOF\n+\n+cat > patch4.patch <<\\EOF\n+diff --git a/main.c b/main.c\n+--- a/main.c\n++++ b/main.c\n+@@ -21,1 +21,1 @@\n+ \t}; \n+\\ No newline at end of file\n+EOF\n+\n+cat > patch5.patch <<\\EOF\n+diff --git a/main.c b/main.c\n+--- a/main.c\n++++ b/main.c\n+@@ -2,1 +2,1 @@\n+ \tvoid print_int(int num);\n+EOF\n+\n+cat > main.c.final <<\\EOF\n+#include <stdio.h>\n+\n+void print_int(int num);\n+int func(int num);\n+\n+int main() {\n+       int i;\n+\n+       for (i = 0; i < 10; i++) {\n+               print_int(func(i)); /* stuff */\n+       }\n+\n+\tprintf(\"\\n\");\n+\n+       return 0;\n+}\n+\n+int func(int num) {\n+       return num * num;\n+}\n+\n+void print_int(int num) {\n+       printf(\"%d\", num);\n+}\n+EOF\n+\n+test_expect_success \"S = patch1\" \\\n+    'git-apply patch1.patch'\n+\n+test_expect_failure \"F = patch2\" \\\n+    'git-apply patch2.patch'\n+\n+git config apply.ignore-whitespace true\n+\n+test_expect_success \"S = patch2 (--ignore-whitespace)\" \\\n+    'git-apply patch2.patch'\n+\n+test_expect_failure \"F = patch3 (missing string at EOL)\" \\\n+    'git-apply patch3.patch'\n+\n+test_expect_failure \"F = patch4 (missing EOL at EOF)\" \\\n+    'git-apply patch4.patch'\n+\n+test_expect_success \"S = patch5 (leading whitespace)\" \\\n+    'git-apply patch5.patch'\n+\n+test_expect_success \"S = main.c.final\" \\\n+    'diff -q main.c main.c.final'\n+\n+rm -f main.c\n+test_expect_success \"S = patch1 (--ignore-whitespace)\" \\\n+    'git-apply patch1.patch'\n+\n+test_expect_failure \"F = patch5 (leading whitespace)\" \\\n+    'git-apply --no-ignore-whitespace patch5.patch'\n+\n+test_done\n+\n+\n-- \n1.6.3.3.511.gcffae6.dirty\n"},{"id":"118993","messageId":"7vljm84htf.fsf@alter.siamese.dyndns.org","threadId":"20264","inReplyTo":"1248814820-25367-1-git-send-email-giuseppe.bilotta@gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-28T21:29:48Z","receivedAt":"2009-07-28T21:29:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n\n> @@ -205,6 +209,9 @@ running `git apply --directory=modules/git-gui`.\n>  Configuration\n>  -------------\n>  \n> +apply.ignore-whitespace::\n> +\tSet this boolean configuration flag if you want to ignore whitespace\n> +\tdifferences to be ignored by default.\n\nThat's a strange sentence.\n\n\tWhen set to true, changes in amount of whitespace are ignored.\n\nI am not happy with the name --ignore-whitespace.\n\nPerhaps --ignore-space-change, to be consistent with a \"git diff\" option,\nwould be more appropriate.  Doing so has an added benefit of leaving the\ndoor open to add --ignore-all-space option to the patch application side\nlater.\n\n> +\t\t/*\n> +\t\t * Skip whitespace inside. We check for whitespace on\n> +\t\t * both buffers because we don't want \"a b\" to match\n> +\t\t * \"ab\"\n\n\t\t * but that is only true when --ignore-space-change\n                 * is in effect.\n\t\t *\n                 * If you want to match \"if(a > b)\" with \"if (a > b)\",\n                 * please add --ignore-all-space option and use it.\n\n    ;-)\n\nIf I am reading the patch correctly, use of this option always disables\nchecks and corrections of whitespace errors.  I personally feel that\nsomebody who is willing to accept a patch that has whitespace breakages\nthat needs this option would not care, but the documentation should warn\nabout it at the minimum.\n\nNeedless to say, a lot better option is not to disable the checks and\ncorrections at all.  After all, this \"ignore space change\" option is about\nmatching the common context lines and replaced/removed contents before the\nchange, and checks and corrections are about added/replaced contents after\nthe change.  They should be orthogonal.\n"},{"id":"119018","messageId":"cb7bb73a0907282333g26efd1d8y7d913fba8a426aa5@mail.gmail.com","threadId":"20264","inReplyTo":"7vljm84htf.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-29T06:33:18Z","receivedAt":"2009-07-29T06:33:18Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Tue, Jul 28, 2009 at 11:29 PM, Junio C Hamano<gitster@pobox.com> wrote:\n> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n>\n>> @@ -205,6 +209,9 @@ running `git apply --directory=modules/git-gui`.\n>>  Configuration\n>>  -------------\n>>\n>> +apply.ignore-whitespace::\n>> +     Set this boolean configuration flag if you want to ignore whitespace\n>> +     differences to be ignored by default.\n>\n> That's a strange sentence.\n>\n>        When set to true, changes in amount of whitespace are ignored.\n\nIndeed, my sentene was horrible.\n\n> I am not happy with the name --ignore-whitespace.\n>\n> Perhaps --ignore-space-change, to be consistent with a \"git diff\" option,\n> would be more appropriate.  Doing so has an added benefit of leaving the\n> door open to add --ignore-all-space option to the patch application side\n> later.\n\nOn the other hand, --ignore-whitespace matches the option name (and\nbehavior) of the 'patch' command (just like \"git diff\"'s matches the\n'diff' option name and behavior). Principle of least surprise says\nthat someone coming to git from raw diff/patch setups would expect\n--ignore-whitespace on the patch side.\n\nA possible future expansion to allow ignoring all whitespace\ncompletely would be to allow --ignore-whitespace=all\n\n> If I am reading the patch correctly, use of this option always disables\n> checks and corrections of whitespace errors.\n\nNot exactly. Whitespace correction is not attempted to try matching\ncontext lines, but the whitespace correction on the new lines is still\napplied.\n\n> I personally feel that\n> somebody who is willing to accept a patch that has whitespace breakages\n> that needs this option would not care\n\nIndeed, my first patch fell through to the whitespace correction, I\nchanged it per your suggestion.\n\n> but the documentation should warn\n> about it at the minimum.\n\nThe code comments does mention that context line whitespace correction\nthat will be skipped. I'll add a note about it in the man page.\n\n> Needless to say, a lot better option is not to disable the checks and\n> corrections at all.  After all, this \"ignore space change\" option is about\n> matching the common context lines and replaced/removed contents before the\n> change, and checks and corrections are about added/replaced contents after\n> the change.  They should be orthogonal.\n\nThey are, for new lines.\n\nActually, one thing that I've been thinking about doing is to adjust\nthe new lines to match the kind of whitespace change the context line\nunderwent. Example: if all the context lines had the change 4 spaces\n-> tab, it would be nice to have the new lines undergo the same\nchange. However, this is going to be rather hard to implement.\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"119025","messageId":"7vab2oynhm.fsf@alter.siamese.dyndns.org","threadId":"20264","inReplyTo":"cb7bb73a0907282333g26efd1d8y7d913fba8a426aa5@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-29T07:09:09Z","receivedAt":"2009-07-29T07:09:09Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n\n> Actually, one thing that I've been thinking about doing is to adjust\n> the new lines to match the kind of whitespace change the context line\n> underwent. Example: if all the context lines had the change 4 spaces\n> -> tab, it would be nice to have the new lines undergo the same\n> change. However, this is going to be rather hard to implement.\n\nDoing so will be actively wrong.\n\nIn the case of \"whitespace=fix\", it is justifiable to update ws broken\ncontext lines while applying a ws corrected patch to a ws broken target,\nand it also is justifiable not to update context lines while applying a ws\nbroken patch to a ws corrected target, because it is clear which one has\nthe correct whitespace layout (i.e. output of ws_fix_copy() by definition\nis the correct outcome).  But in your example, it is not clear if the\nlayout using 4 spaces is correct or the one with a tab.  The tool should\nrefrain from guessing in such a case.\n"},{"id":"119030","messageId":"cb7bb73a0907290120x72d0ae99p7cfdd2b88264a24a@mail.gmail.com","threadId":"20264","inReplyTo":"7vab2oynhm.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-29T08:20:44Z","receivedAt":"2009-07-29T08:20:44Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Wed, Jul 29, 2009 at 9:09 AM, Junio C Hamano<gitster@pobox.com> wrote:\n> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n>\n>> Actually, one thing that I've been thinking about doing is to adjust\n>> the new lines to match the kind of whitespace change the context line\n>> underwent. Example: if all the context lines had the change 4 spaces\n>> -> tab, it would be nice to have the new lines undergo the same\n>> change. However, this is going to be rather hard to implement.\n>\n> Doing so will be actively wrong.\n>\n> In the case of \"whitespace=fix\", it is justifiable to update ws broken\n> context lines while applying a ws corrected patch to a ws broken target,\n> and it also is justifiable not to update context lines while applying a ws\n> broken patch to a ws corrected target, because it is clear which one has\n> the correct whitespace layout (i.e. output of ws_fix_copy() by definition\n> is the correct outcome).  But in your example, it is not clear if the\n> layout using 4 spaces is correct or the one with a tab.  The tool should\n> refrain from guessing in such a case.\n\nI was thinking more about consistency than 'correctness'  in this\ncase, actually. Typical scenario would be: patch is created for a file\nusing a given whitespace convention (e.g. 4 spaces). File is updated\nto match the rest of the project (tabs). Patch would now introduce the\nwrong whitespace convention for the new lines.\n\nOf course, whitespace can (and should) be fixed a posteriori, but when\ndoing a rebase this can get quite annoying. So some kind of automatic\nway to do it would be nice. But I don't think I'd get around to such a\nfeature any time soon. (Also, the merge case has a higher priority.)\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"119034","messageId":"7vws5rx4qt.fsf@alter.siamese.dyndns.org","threadId":"20264","inReplyTo":"cb7bb73a0907290120x72d0ae99p7cfdd2b88264a24a@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-29T08:39:22Z","receivedAt":"2009-07-29T08:39:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n\n> I was thinking more about consistency than 'correctness'  in this\n> case, actually. Typical scenario would be: patch is created for a file\n> using a given whitespace convention (e.g. 4 spaces). File is updated\n> to match the rest of the project (tabs). Patch would now introduce the\n> wrong whitespace convention for the new lines.\n\nYou are assuming that the patch is always based on a wrong convention and\nthe target always uses the right convention.  In general, however, you\ncannot tell which way the \"consisitency\" should go --- often you have to\napply a patch based on a fixed codebase to an older version.\n"},{"id":"119035","messageId":"20090729174000.6117@nanako3.lavabit.com","threadId":"20264","inReplyTo":"cb7bb73a0907282333g26efd1d8y7d913fba8a426aa5@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Nanako Shiraishi","fromEmail":"nanako3@lavabit.com","sentAt":"2009-07-29T08:40:00Z","receivedAt":"2009-07-29T08:40:00Z","isPatch":false,"sender":{"key":"nanako3@lavabit.com","avatar":"https://gravatar.com/avatar/3777b9e201c5883a62b1a6fdf7c53f2d712d1d80989146063ea861e33aad72a8?d=mp&s=160"},"body":"Quoting Giuseppe Bilotta <giuseppe.bilotta@gmail.com>\n\n>> Perhaps --ignore-space-change, to be consistent with a \"git diff\" option,\n>> would be more appropriate. Doing so has an added benefit of leaving the\n>> door open to add --ignore-all-space option to the patch application side\n>> later.\n>\n> On the other hand, --ignore-whitespace matches the option name (and\n> behavior) of the 'patch' command (just like \"git diff\"'s matches the\n> 'diff' option name and behavior). Principle of least surprise says\n> that someone coming to git from raw diff/patch setups would expect\n> --ignore-whitespace on the patch side.\n\nNot everybody shares your diff/patch background.\n\nI wouldn't be surprised if git were the first system they ever learn for\nmajority of users of version control systems in this century, especially\nbecause now there are many books written on it.\n\nIsn't it more important for git to be internally consistent across its\ncommands for such an audience to satisfy the principle of least surprise?\n\n-- \nNanako Shiraishi\nhttp://ivory.ap.teacup.com/nanako3/\n"},{"id":"119042","messageId":"cb7bb73a0907290205t6402c5dbob3d4a1663ec39135@mail.gmail.com","threadId":"20264","inReplyTo":"7vws5rx4qt.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-29T09:05:40Z","receivedAt":"2009-07-29T09:05:40Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Wed, Jul 29, 2009 at 10:39 AM, Junio C Hamano<gitster@pobox.com> wrote:\n> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n>\n>> I was thinking more about consistency than 'correctness'  in this\n>> case, actually. Typical scenario would be: patch is created for a file\n>> using a given whitespace convention (e.g. 4 spaces). File is updated\n>> to match the rest of the project (tabs). Patch would now introduce the\n>> wrong whitespace convention for the new lines.\n>\n> You are assuming that the patch is always based on a wrong convention and\n> the target always uses the right convention.\n\nNo, I'm just assuming that the lines should have consistent whitespace\n\n> In general, however, you\n> cannot tell which way the \"consisitency\" should go --- often you have to\n> apply a patch based on a fixed codebase to an older version.\n\nConsistency should go the way of the context lines. So if the\nconvention changed and you're backporting changes, the changes would\nuse the old convention on the old codebase, and the new convention on\nthe new codebase, because that's what the context lines would direct\nthe new lines to.\n\nOf course, this is all very abstract reasoning because I don't even\nthink the feature can be implemented at all robustly (too much 'AI'\nwork, IMO).\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"119044","messageId":"cb7bb73a0907290209u11b2055bv9889ccd5c4a92911@mail.gmail.com","threadId":"20264","inReplyTo":"20090729174000.6117@nanako3.lavabit.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-29T09:09:12Z","receivedAt":"2009-07-29T09:09:12Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Wed, Jul 29, 2009 at 10:40 AM, Nanako Shiraishi<nanako3@lavabit.com> wrote:\n> Quoting Giuseppe Bilotta <giuseppe.bilotta@gmail.com>\n>\n>>> Perhaps --ignore-space-change, to be consistent with a \"git diff\" option,\n>>> would be more appropriate. Doing so has an added benefit of leaving the\n>>> door open to add --ignore-all-space option to the patch application side\n>>> later.\n>>\n>> On the other hand, --ignore-whitespace matches the option name (and\n>> behavior) of the 'patch' command (just like \"git diff\"'s matches the\n>> 'diff' option name and behavior). Principle of least surprise says\n>> that someone coming to git from raw diff/patch setups would expect\n>> --ignore-whitespace on the patch side.\n>\n> Not everybody shares your diff/patch background.\n>\n> I wouldn't be surprised if git were the first system they ever learn for\n> majority of users of version control systems in this century, especially\n> because now there are many books written on it.\n\nThis is something I hadn't considered.\n\n> Isn't it more important for git to be internally consistent across its\n> commands for such an audience to satisfy the principle of least surprise?\n\nWould it be ok if I had the option and command line option turn into\nignore-space-change and keep ignore-whitespace as a synonym? Or would\nthat be too much?\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"119201","messageId":"94a0d4530907301727h171a2581ybee2a5b2d77e7c05@mail.gmail.com","threadId":"20264","inReplyTo":"20090729174000.6117@nanako3.lavabit.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-07-31T00:27:37Z","receivedAt":"2009-07-31T00:27:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Jul 29, 2009 at 8:40 AM, Nanako Shiraishi<nanako3@lavabit.com> wrote:\n> Quoting Giuseppe Bilotta <giuseppe.bilotta@gmail.com>\n>\n>>> Perhaps --ignore-space-change, to be consistent with a \"git diff\" option,\n>>> would be more appropriate. Doing so has an added benefit of leaving the\n>>> door open to add --ignore-all-space option to the patch application side\n>>> later.\n>>\n>> On the other hand, --ignore-whitespace matches the option name (and\n>> behavior) of the 'patch' command (just like \"git diff\"'s matches the\n>> 'diff' option name and behavior). Principle of least surprise says\n>> that someone coming to git from raw diff/patch setups would expect\n>> --ignore-whitespace on the patch side.\n>\n> Not everybody shares your diff/patch background.\n>\n> I wouldn't be surprised if git were the first system they ever learn for\n> majority of users of version control systems in this century, especially\n> because now there are many books written on it.\n\nThat's not relevant, \"white space\" is an already used concept.\n\nGoogle:\nignore space change: 17,300,000\nignore white space: 181,000,000\n\n> Isn't it more important for git to be internally consistent across its\n> commands for such an audience to satisfy the principle of least surprise?\n\nPerhaps, but you are forgetting the option to change the current\ncommands' arguments.\n\n-- \nFelipe Contreras\n"},{"id":"119204","messageId":"7v3a8d65kv.fsf@alter.siamese.dyndns.org","threadId":"20264","inReplyTo":"94a0d4530907301727h171a2581ybee2a5b2d77e7c05@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-31T00:48:00Z","receivedAt":"2009-07-31T00:48:00Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Felipe Contreras <felipe.contreras@gmail.com> writes:\n\n> Google:\n> ignore space change: 17,300,000\n> ignore white space: 181,000,000\n\nBut that is not relevant either.  \"ignore white space\" is a superset of\n\"ignore space change\", iow the latter has more specific meaning than the\nformer.  It is not surprising to see that search engines find larger\nnumber of references to more general terms than more specific ones.\n"},{"id":"119278","messageId":"94a0d4530907310838nbca0037u1a192dc07a379e66@mail.gmail.com","threadId":"20264","inReplyTo":"7v3a8d65kv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2009-07-31T15:38:37Z","receivedAt":"2009-07-31T15:38:37Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Fri, Jul 31, 2009 at 12:48 AM, Junio C Hamano<gitster@pobox.com> wrote:\n> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>\n>> Google:\n>> ignore space change: 17,300,000\n>> ignore white space: 181,000,000\n>\n> But that is not relevant either.  \"ignore white space\" is a superset of\n> \"ignore space change\", iow the latter has more specific meaning than the\n> former.  It is not surprising to see that search engines find larger\n> number of references to more general terms than more specific ones.\n\nThe fact remains the same: white space is a much more used term, and\nIMHO the only one that really matters.\n\n-- \nFelipe Contreras\n"},{"id":"119284","messageId":"cb7bb73a0907310916i309c99cax2f2d5aa02084103f@mail.gmail.com","threadId":"20264","inReplyTo":"94a0d4530907310838nbca0037u1a192dc07a379e66@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-31T16:16:43Z","receivedAt":"2009-07-31T16:16:43Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Jul 31, 2009 at 5:38 PM, Felipe\nContreras<felipe.contreras@gmail.com> wrote:\n> On Fri, Jul 31, 2009 at 12:48 AM, Junio C Hamano<gitster@pobox.com> wrote:\n>> Felipe Contreras <felipe.contreras@gmail.com> writes:\n>>\n>>> Google:\n>>> ignore space change: 17,300,000\n>>> ignore white space: 181,000,000\n>>\n>> But that is not relevant either.  \"ignore white space\" is a superset of\n>> \"ignore space change\", iow the latter has more specific meaning than the\n>> former.  It is not surprising to see that search engines find larger\n>> number of references to more general terms than more specific ones.\n>\n> The fact remains the same: white space is a much more used term, and\n> IMHO the only one that really matters.\n\nBefore I go on with the next revision of the patch, I would like to\nhave some kind of agreed convention to implement.\n\nMy suggestion would be the following:\n(1) implement options --ignore-space-change, --ignore-all-space\nmirroring their 'git diff' meaning.\n(2) add --ignore-whitespace as a synonym to --ignore-space-change, for\nconsistency with 'patch'\n(3) apply.ignore-whitespace accepts values\n     * false,no,none,0 to mean no whitespace ignoring\n     * true,yes,change,1 to mean ignore whitespace change\n     * all,2 to mean ignore all whitespace\n\nObjections?\n\n\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"},{"id":"119293","messageId":"7v1vnwsreu.fsf@alter.siamese.dyndns.org","threadId":"20264","inReplyTo":"cb7bb73a0907310916i309c99cax2f2d5aa02084103f@mail.gmail.com","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-07-31T17:17:45Z","receivedAt":"2009-07-31T17:17:45Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n\n> Before I go on with the next revision of the patch, I would like to\n> have some kind of agreed convention to implement.\n>\n> My suggestion would be the following:\n> (1) implement options --ignore-space-change, --ignore-all-space\n> mirroring their 'git diff' meaning.\n> (2) add --ignore-whitespace as a synonym to --ignore-space-change, for\n> consistency with 'patch'\n> (3) apply.ignore-whitespace accepts values\n>      * false,no,none,0 to mean no whitespace ignoring\n>      * true,yes,change,1 to mean ignore whitespace change\n>      * all,2 to mean ignore all whitespace\n\nI'd suggest taking one small bite at a time.  You do not have code to do\nthe ignore-all-space semantics that has been reviewed, and you neither\nhave the configuration variables.  So my preference would be to do in the\nfirst round the first half of (1) with (2), docs, tests and nothing else.\n\nA later follow-up patch would complete your (1) and (2) by supporting\nignore-all-space.  And perhaps you would give it --ignore-all-whitespace\nsynonym perhaps?  You may want to ask \"GNU patch\" people if they are\ninterested in ignoring all whitespaces, and if so what their plan is to\nname that option, so that you can use the same name.\n\nAs to configuration:\n\n - I think the naming convention (I know, there are existing violators,\n   but that is not an excuse to add new ones) is without dashes (again, I\n   know I personally do not like CamelCase but that is what we have);\n\n - I personally think 0/1/2 would be more cluttering than they are useful.\n\n - I'd say \"no (never, none)\", \"change\", \"all\".  You could throw in\n   \"false\" if you want, as declining this option is quite boolean-ish, but\n   activating it is _not_ boolean decision and I would suggest actively\n   keeping \"true\" or \"yes\" out of the choices.  Otherwise anybody who is\n   tempted to answer \"yes\" has to ask himself \"Ok, I want to say 'yes' but\n   which semantics does it mean?  What would I be ignoring?\"\n\nThat non-booleanness of \"true\" is why I am somewhat negative on your (2)\nabove.  It would only be there for people who know \"GNU patch\" because\nthey would understand it.\n"},{"id":"119304","messageId":"cb7bb73a0907311222h49caf016pb9b4a4fd2bd766a@mail.gmail.com","threadId":"20264","inReplyTo":"7v1vnwsreu.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCHv3] git apply: option to ignore whitespace differences","fromName":"Giuseppe Bilotta","fromEmail":"giuseppe.bilotta@gmail.com","sentAt":"2009-07-31T19:22:09Z","receivedAt":"2009-07-31T19:22:09Z","isPatch":false,"sender":{"key":"giuseppe.bilotta@gmail.com","avatar":"https://avatars.githubusercontent.com/u/1464?v=4"},"body":"On Fri, Jul 31, 2009 at 7:17 PM, Junio C Hamano<gitster@pobox.com> wrote:\n> Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:\n>\n>> Before I go on with the next revision of the patch, I would like to\n>> have some kind of agreed convention to implement.\n>>\n>> My suggestion would be the following:\n>> (1) implement options --ignore-space-change, --ignore-all-space\n>> mirroring their 'git diff' meaning.\n>> (2) add --ignore-whitespace as a synonym to --ignore-space-change, for\n>> consistency with 'patch'\n>> (3) apply.ignore-whitespace accepts values\n>>      * false,no,none,0 to mean no whitespace ignoring\n>>      * true,yes,change,1 to mean ignore whitespace change\n>>      * all,2 to mean ignore all whitespace\n>\n> I'd suggest taking one small bite at a time.\n\nSure.\n\n> A later follow-up patch would complete your (1) and (2) by supporting\n> ignore-all-space.  And perhaps you would give it --ignore-all-whitespace\n> synonym perhaps?  You may want to ask \"GNU patch\" people if they are\n> interested in ignoring all whitespaces, and if so what their plan is to\n> name that option, so that you can use the same name.\n\nI was thinking about making --ignore-whitespace (I'd rather keep the\n-- because that's what patch goes for) accept an optional argument,\nallowing e.g. --ignore-whitespace=no to overrule the config option. In\nthis case we would have --ignore-whitespace=all as synonym to\n-ignore-all-space. It would also make the --ignore-whitespace option\nmore in line with the ignorewhitespace config\n\n-- \nGiuseppe \"Oblomov\" Bilotta\n"}]}