{"thread":{"id":"45932","subject":"[PATCH] compat/regex: fix compilation on Windows","startedAt":"2017-05-11T13:50:56Z","lastAt":"2017-05-15T01:39:10Z","messageCount":10,"participants":["Johannes Schindelin","Ævar Arnfjörð Bjarmason","Junio C Hamano","Ramsay Jones"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"319406","messageId":"6a6782863a74432094a1d7fba7f2477991ef2d16.1494510612.git.johannes.schindelin@gmx.de","threadId":"45932","inReplyTo":null,"subject":"[PATCH] compat/regex: fix compilation on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-05-11T13:50:21Z","receivedAt":"2017-05-11T13:50:56Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"The real issue here is that GNU awk's regex implementation assumes a bit\ntoo much about the relative sizes of pointers and long integers. What they\nreally want is to use intptr_t.\n\nThis patch recapitulates what 56a1a3ab449 (Silence GCC's \"cast of pointer\nto integer of a different size\" warning, 2015-10-26) did to our previous\ncopy of GNU awk's regex engine.\n\nSigned-off-by: Johannes Schindelin \n---\nPublished-As: https://github.com/dscho/git/releases/tag/compat-regex-fixes-v1\nFetch-It-Via: git fetch https://github.com/dscho/git compat-regex-fixes-v1\n\n .../0003-Use-intptr_t-instead-of-long.patch | 22 ++++++++++++++++++++++\n compat/regex/regcomp.c | 4 ++--\n 2 files changed, 24 insertions(+), 2 deletions(-)\n create mode 100644 compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n\ndiff --git a/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\nnew file mode 100644\nindex 00000000000..246ff256fb8\n--- /dev/null\n+++ b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n@@ -0,0 +1,22 @@\n+diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\n+index 5e9ea26cd46..e6469167a80 100644\n+--- a/compat/regex/regcomp.c\n++++ b/compat/regex/regcomp.c\n+@@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n+ old_tree = NULL;\n+ \n+ if (elem->token.type == SUBEXP)\n+- postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n++ postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n+ \n+ tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n+ if (BE (tree == NULL, 0))\n+@@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n+ static reg_errcode_t\n+ mark_opt_subexp (void *extra, bin_tree_t *node)\n+ {\n+- int idx = (int) (long) extra;\n++ int idx = (int) (intptr_t) extra;\n+ if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n+ node->token.opt_subexp = 1;\n+ \ndiff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\nindex 5e9ea26cd46..e6469167a80 100644\n--- a/compat/regex/regcomp.c\n+++ b/compat/regex/regcomp.c\n@@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n old_tree = NULL;\n \n if (elem->token.type == SUBEXP)\n- postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n+ postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n \n tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n if (BE (tree == NULL, 0))\n@@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n static reg_errcode_t\n mark_opt_subexp (void *extra, bin_tree_t *node)\n {\n- int idx = (int) (long) extra;\n+ int idx = (int) (intptr_t) extra;\n if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n node->token.opt_subexp = 1;\n \n\nbase-commit: 4e23cefb4da69a2d884c2d5a303825f40008ca42\n-- \n2.12.2.windows.2.800.gede8f145e06\n"},{"id":"319408","messageId":"CACBZZX7i4Sz2w1obCVEKKoq+a+SmzkJ6AYDvaVQgkGRGDU+rng@mail.gmail.com","threadId":"45932","inReplyTo":"6a6782863a74432094a1d7fba7f2477991ef2d16.1494510612.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-11T14:30:13Z","receivedAt":"2017-05-11T14:30:45Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 3:50 PM, Johannes Schindelin\n wrote:\n> The real issue here is that GNU awk's regex implementation assumes a bit\n> too much about the relative sizes of pointers and long integers. What they\n> really want is to use intptr_t.\n\nThanks, looks good!\n\n> This patch recapitulates what 56a1a3ab449 (Silence GCC's \"cast of pointer\n> to integer of a different size\" warning, 2015-10-26) did to our previous\n> copy of GNU awk's regex engine.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n> Published-As: https://github.com/dscho/git/releases/tag/compat-regex-fixes-v1\n> Fetch-It-Via: git fetch https://github.com/dscho/git compat-regex-fixes-v1\n>\n> .../0003-Use-intptr_t-instead-of-long.patch | 22 ++++++++++++++++++++++\n> compat/regex/regcomp.c | 4 ++--\n> 2 files changed, 24 insertions(+), 2 deletions(-)\n> create mode 100644 compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n>\n> diff --git a/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n> new file mode 100644\n> index 00000000000..246ff256fb8\n> --- /dev/null\n> +++ b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n> @@ -0,0 +1,22 @@\n> +diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\n> +index 5e9ea26cd46..e6469167a80 100644\n> +--- a/compat/regex/regcomp.c\n> ++++ b/compat/regex/regcomp.c\n> +@@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n> + old_tree = NULL;\n> +\n> + if (elem->token.type == SUBEXP)\n> +- postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n> ++ postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n> +\n> + tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n> + if (BE (tree == NULL, 0))\n> +@@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n> + static reg_errcode_t\n> + mark_opt_subexp (void *extra, bin_tree_t *node)\n> + {\n> +- int idx = (int) (long) extra;\n> ++ int idx = (int) (intptr_t) extra;\n> + if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n> + node->token.opt_subexp = 1;\n> +\n> diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\n> index 5e9ea26cd46..e6469167a80 100644\n> --- a/compat/regex/regcomp.c\n> +++ b/compat/regex/regcomp.c\n> @@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n> old_tree = NULL;\n>\n> if (elem->token.type == SUBEXP)\n> - postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n> + postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n>\n> tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n> if (BE (tree == NULL, 0))\n> @@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n> static reg_errcode_t\n> mark_opt_subexp (void *extra, bin_tree_t *node)\n> {\n> - int idx = (int) (long) extra;\n> + int idx = (int) (intptr_t) extra;\n> if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n> node->token.opt_subexp = 1;\n>\n>\n> base-commit: 4e23cefb4da69a2d884c2d5a303825f40008ca42\n> --\n> 2.12.2.windows.2.800.gede8f145e06\n"},{"id":"319494","messageId":"xmqqd1be98kk.fsf@gitster.mtv.corp.google.com","threadId":"45932","inReplyTo":"6a6782863a74432094a1d7fba7f2477991ef2d16.1494510612.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-12T01:18:19Z","receivedAt":"2017-05-12T01:18:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> The real issue here is that GNU awk's regex implementation assumes a bit\n> too much about the relative sizes of pointers and long integers. What they\n> really want is to use intptr_t.\n\nGood. I got annoyed enough to do the same myself before opening my\nmailbox. One thing that is curious about your version is that it\nstill has \"#include \" behind HAVE_STDINT_H; when I tried\nto compile an equivalent of your change last night, the compilation\nfailed because intptr_t wasn't available without exposing \n\nWhere is Windows build getting its intptr_t, I wonder.\n"},{"id":"319541","messageId":"alpine.DEB.2.21.1.1705121219150.146734@virtualbox","threadId":"45932","inReplyTo":"xmqqd1be98kk.fsf@gitster.mtv.corp.google.com","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-05-12T10:25:44Z","receivedAt":"2017-05-12T18:45:40Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Junio,\n\nOn Fri, 12 May 2017, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > The real issue here is that GNU awk's regex implementation assumes a\n> > bit too much about the relative sizes of pointers and long integers.\n> > What they really want is to use intptr_t.\n> \n> Good. I got annoyed enough to do the same myself before opening my\n> mailbox. One thing that is curious about your version is that it still\n> has \"#include \" behind HAVE_STDINT_H; when I tried to compile\n> an equivalent of your change last night, the compilation failed because\n> intptr_t wasn't available without exposing \n> \n> Where is Windows build getting its intptr_t, I wonder.\n\nI'd place a bet on this part of compat/mingw.h for GCC builds:\n\n\t#ifdef __MINGW64_VERSION_MAJOR\n\t#include \n\t#include \n\ttypedef _sigset_t sigset_t;\n\t#endif\n\nand on this part of git-compat-util.h for MSVC builds:\n\n\t#ifndef NO_INTTYPES_H\n\t#include \n\t#else\n\t#include \n\t#endif\n\nFor the record, it seems that our current version of compat/regex/regex.c\nhas this:\n\n\t/* On some systems, limits.h sets RE_DUP_MAX to a lower value than\n\t GNU regex allows. Include it before , which correctly\n\t #undefs RE_DUP_MAX and sets it to the right value. */\n\t#include \n\t#include \n\nwhile the one in `pu` lacks the last line. That may be the reason why\nthings compiled neatly before, and stopped working for you now.\n\nSo yeah, I think you are right in that the HAVE_STDINT_H guard needs to be\nremoved either before my patch, or squashed into it.\n\nCiao,\nDscho\n"},{"id":"319566","messageId":"413493c2-24ee-e085-f4cc-371b677d2d02@ramsayjones.plus.com","threadId":"45932","inReplyTo":"alpine.DEB.2.21.1.1705121219150.146734@virtualbox","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-05-12T21:02:58Z","receivedAt":"2017-05-12T21:03:05Z","isPatch":true,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 12/05/17 11:25, Johannes Schindelin wrote:\n> Hi Junio,\n> \n> On Fri, 12 May 2017, Junio C Hamano wrote:\n> \n>> Johannes Schindelin writes:\n>>\n>>> The real issue here is that GNU awk's regex implementation assumes a\n>>> bit too much about the relative sizes of pointers and long integers.\n>>> What they really want is to use intptr_t.\n>>\n>> Good. I got annoyed enough to do the same myself before opening my\n>> mailbox. One thing that is curious about your version is that it still\n>> has \"#include \" behind HAVE_STDINT_H; when I tried to compile\n>> an equivalent of your change last night, the compilation failed because\n>> intptr_t wasn't available without exposing \n>>\n>> Where is Windows build getting its intptr_t, I wonder.\n> \n> I'd place a bet on this part of compat/mingw.h for GCC builds:\n> \n> \t#ifdef __MINGW64_VERSION_MAJOR\n> \t#include \n> \t#include \n> \ttypedef _sigset_t sigset_t;\n> \t#endif\n> \n> and on this part of git-compat-util.h for MSVC builds:\n> \n> \t#ifndef NO_INTTYPES_H\n> \t#include \n> \t#else\n> \t#include \n> \t#endif\n> \n> For the record, it seems that our current version of compat/regex/regex.c\n> has this:\n> \n> \t/* On some systems, limits.h sets RE_DUP_MAX to a lower value than\n> \t GNU regex allows. Include it before , which correctly\n> \t #undefs RE_DUP_MAX and sets it to the right value. */\n> \t#include \n> \t#include \n> \n> while the one in `pu` lacks the last line. That may be the reason why\n> things compiled neatly before, and stopped working for you now.\n\nYep, see commit bd8f005583. ;-P\n\nSo, sparse is, once again, complaining about the SIZE_MAX macro\nredefinition. (Along with two other warnings, one of which is a\n_very_ long standing warning and one of which is new - I have\nyet to investigate).\n\nATB,\nRamsay Jones\n\n"},{"id":"319568","messageId":"xmqqy3u14vim.fsf@gitster.mtv.corp.google.com","threadId":"45932","inReplyTo":"alpine.DEB.2.21.1.1705121219150.146734@virtualbox","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-12T21:26:09Z","receivedAt":"2017-05-12T21:26:16Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> I'd place a bet on this part of compat/mingw.h for GCC builds:\n>\n> \t#ifdef __MINGW64_VERSION_MAJOR\n> \t#include \n> \t#include \n> \ttypedef _sigset_t sigset_t;\n> \t#endif\n>\n> and on this part of git-compat-util.h for MSVC builds:\n>\n> \t#ifndef NO_INTTYPES_H\n> \t#include \n> \t#else\n> \t#include \n> \t#endif\n\nYeah, but I had an impression that git-compat-util.h was not in use\nto build compat/regex/regex.o (regex.c #include's regcomp.c which is\na rather unusual arragement), and that was why I am wondering.\n\n> For the record, it seems that our current version of compat/regex/regex.c\n> has this:\n>\n> \t/* On some systems, limits.h sets RE_DUP_MAX to a lower value than\n> \t GNU regex allows. Include it before , which correctly\n> \t #undefs RE_DUP_MAX and sets it to the right value. */\n> \t#include \n> \t#include \n>\n> while the one in `pu` lacks the last line. That may be the reason why\n> things compiled neatly before, and stopped working for you now.\n\nYes, that explains how the old one worked and the new one didn't\nwithout dropping \"#ifdef HAVE_STDINT_H\".\n\nThanks.\n"},{"id":"319574","messageId":"CACBZZX4UUwzRQmyH8joYaqHnuVTjVtGBHp+iZKcnAnwoM_ZJhg@mail.gmail.com","threadId":"45932","inReplyTo":"6a6782863a74432094a1d7fba7f2477991ef2d16.1494510612.git.johannes.schindelin@gmx.de","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-12T22:27:51Z","receivedAt":"2017-05-12T22:28:18Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, May 11, 2017 at 3:50 PM, Johannes Schindelin\n wrote:\n> The real issue here is that GNU awk's regex implementation assumes a bit\n> too much about the relative sizes of pointers and long integers. What they\n> really want is to use intptr_t.\n>\n> This patch recapitulates what 56a1a3ab449 (Silence GCC's \"cast of pointer\n> to integer of a different size\" warning, 2015-10-26) did to our previous\n> copy of GNU awk's regex engine.\n>\n> Signed-off-by: Johannes Schindelin \n> ---\n> Published-As: https://github.com/dscho/git/releases/tag/compat-regex-fixes-v1\n> Fetch-It-Via: git fetch https://github.com/dscho/git compat-regex-fixes-v1\n>\n> .../0003-Use-intptr_t-instead-of-long.patch | 22 ++++++++++++++++++++++\n> compat/regex/regcomp.c | 4 ++--\n> 2 files changed, 24 insertions(+), 2 deletions(-)\n> create mode 100644 compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n>\n> diff --git a/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n> new file mode 100644\n> index 00000000000..246ff256fb8\n> --- /dev/null\n> +++ b/compat/regex/patches/0003-Use-intptr_t-instead-of-long.patch\n> @@ -0,0 +1,22 @@\n> +diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\n> +index 5e9ea26cd46..e6469167a80 100644\n> +--- a/compat/regex/regcomp.c\n> ++++ b/compat/regex/regcomp.c\n> +@@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n> + old_tree = NULL;\n> +\n> + if (elem->token.type == SUBEXP)\n> +- postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n> ++ postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n> +\n> + tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n> + if (BE (tree == NULL, 0))\n> +@@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n> + static reg_errcode_t\n> + mark_opt_subexp (void *extra, bin_tree_t *node)\n> + {\n> +- int idx = (int) (long) extra;\n> ++ int idx = (int) (intptr_t) extra;\n> + if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n> + node->token.opt_subexp = 1;\n> +\n> diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c\n> index 5e9ea26cd46..e6469167a80 100644\n> --- a/compat/regex/regcomp.c\n> +++ b/compat/regex/regcomp.c\n> @@ -2641,7 +2641,7 @@ parse_dup_op (bin_tree_t *elem, re_string_t *regexp, re_dfa_t *dfa,\n> old_tree = NULL;\n>\n> if (elem->token.type == SUBEXP)\n> - postorder (elem, mark_opt_subexp, (void *) (long) elem->token.opr.idx);\n> + postorder (elem, mark_opt_subexp, (void *) (intptr_t) elem->token.opr.idx);\n>\n> tree = create_tree (dfa, elem, NULL, (end == -1 ? OP_DUP_ASTERISK : OP_ALT));\n> if (BE (tree == NULL, 0))\n> @@ -3868,7 +3868,7 @@ create_token_tree (re_dfa_t *dfa, bin_tree_t *left, bin_tree_t *right,\n> static reg_errcode_t\n> mark_opt_subexp (void *extra, bin_tree_t *node)\n> {\n> - int idx = (int) (long) extra;\n> + int idx = (int) (intptr_t) extra;\n> if (node->token.type == SUBEXP && node->token.opr.idx == idx)\n> node->token.opt_subexp = 1;\n>\n>\n> base-commit: 4e23cefb4da69a2d884c2d5a303825f40008ca42\n> --\n> 2.12.2.windows.2.800.gede8f145e06\n\nLet's drop this current gawk import series.\n\nAfter talking to the gawk author it turns out it's better to use the\nversion from gnulib, this includes the equivalent of your patch.\n\nThe following one-liner works for me on linux to import that library,\non the master branch:\n\n$ git reset --hard; rm compat/regex/*.[ch]; rm -rfv /tmp/git.rx; test\n-e /tmp/git-gnulib || git clone\nhttps://git.savannah.gnu.org/git/gnulib.git /tmp/git-gnulib; mkdir\n/tmp/git.rx; touch /tmp/git.rx/configure.ac;\n/tmp/git-gnulib/gnulib-tool --lgpl --add-import --dir=/tmp/git.rx\nregex; cp /tmp/git.rx/lib/{intprops.h,reg*} compat/regex/; perl -0666\n-pi.bak -e 's[compat/regex/regex.o: EXTRA_CPPFLAGS =\n\\K[^\\n]+\\n[^\\n]+][]s' Makefile; echo '#define _GNU_SOURCE'\n>compat/regex/config.h\n\nI.e. remove the existing engine, import new one from gnulib, then wipe\nthe extra -D flags that exist now, and define _GNU_SOURCE.\n"},{"id":"319628","messageId":"alpine.DEB.2.21.1.1705131251260.146734@virtualbox","threadId":"45932","inReplyTo":"CACBZZX4UUwzRQmyH8joYaqHnuVTjVtGBHp+iZKcnAnwoM_ZJhg@mail.gmail.com","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-05-13T18:30:20Z","receivedAt":"2017-05-13T18:30:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ævar,\n\nI originally replied in a very verbose manner, going step by step through\nthe \"one-liner\", but decided to rephrase everything.\n\nSo here goes.\n\nOn Sat, 13 May 2017, Ævar Arnfjörð Bjarmason wrote:\n\n> Let's drop this current gawk import series.\n\nWell, the reason why you imported the current gawk regex is that we (you?)\ndecided originally that it'd be easier to go with that one rather than\nwith the gnulib one (which they friendly-forked). If you switch to gnulib,\nI would like to see (in the commit message) the original reason we picked\ngawk (which forked gnulib's regex code, after all), and why that reason no\nlonger applies.\n\nI also would strongly prefer a *non* one-liner, in a commit message that\nadds the relevant source code from gawk or gnulib *verbatim*, followed by\npatches that adjust the code to Git's needs. That way, a future update can\nrepeat the commands outlined in the first commit message and then\ncherry-pick the subsequent patches.\n\nAnd remember that you do not need to clone the entire repository. You can\n1) fetch into the current one, and 2) use a shallow fetch. Example:\n\n\tgit fetch --depth 1 http://git.savannah.gnu.org/r/gawk.git \\\n\t\tgawk-4.1.4\n\nThe next commands could be something like\n\n\tgit read-tree --prefix=compat/regex/ FETCH_HEAD:\n\tgit clean -dfx -- compat/regex/\n\nOh, and please do not use `master`. If Git is any indication, a tagged\nrelease will most often be a bit more robust than any in-between commit.\n\nThanks,\nDscho"},{"id":"319630","messageId":"CACBZZX6Qx+oy83GjTOahUyHM4=gESzX+QNMLrY2DHgdYMo3cNw@mail.gmail.com","threadId":"45932","inReplyTo":"alpine.DEB.2.21.1.1705131251260.146734@virtualbox","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2017-05-13T19:31:12Z","receivedAt":"2017-05-13T19:31:38Z","isPatch":true,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Sat, May 13, 2017 at 8:30 PM, Johannes Schindelin\n wrote:\n> Hi Ævar,\n>\n> I originally replied in a very verbose manner, going step by step through\n> the \"one-liner\", but decided to rephrase everything.\n>\n> So here goes.\n>\n> On Sat, 13 May 2017, Ævar Arnfjörð Bjarmason wrote:\n>\n>> Let's drop this current gawk import series.\n>\n> Well, the reason why you imported the current gawk regex is that we (you?)\n> decided originally that it'd be easier to go with that one rather than\n> with the gnulib one (which they friendly-forked). If you switch to gnulib,\n> I would like to see (in the commit message) the original reason we picked\n> gawk (which forked gnulib's regex code, after all), and why that reason no\n> longer applies.\n\nIt was just easier to extract the code from gawk than gnulib at the\ntime. The thread starting at <20100715220059.GA3312@burratino> has\nsome details.\n\n> I also would strongly prefer a *non* one-liner, in a commit message that\n> adds the relevant source code from gawk or gnulib *verbatim*, followed by\n> patches that adjust the code to Git's needs. That way, a future update can\n> repeat the commands outlined in the first commit message and then\n> cherry-pick the subsequent patches.\n>\n> And remember that you do not need to clone the entire repository. You can\n> 1) fetch into the current one, and 2) use a shallow fetch. Example:\n>\n> git fetch --depth 1 http://git.savannah.gnu.org/r/gawk.git \\\n> gawk-4.1.4\n>\n> The next commands could be something like\n>\n> git read-tree --prefix=compat/regex/ FETCH_HEAD:\n> git clean -dfx -- compat/regex/\n\nSure, if I submit this again I'll update whatever one liner is in\nthere to import it via git.\n\n> Oh, and please do not use `master`. If Git is any indication, a tagged\n> release will most often be a bit more robust than any in-between commit.\n\nThe reason to use the master branch of gawk is that since the last\nrelease only one trivial change has been made to it, but the files\nwere all renamed as well, so it was easier for that one-liner in the\nREADME to use master than the latest release.\n\nIf we move to gnulib we'll also use the master branch, because that's\nwhat you're supposed to do according to their docs, they don't make\nreleases.\n"},{"id":"319737","messageId":"xmqqo9uuyk3u.fsf@gitster.mtv.corp.google.com","threadId":"45932","inReplyTo":"CACBZZX4UUwzRQmyH8joYaqHnuVTjVtGBHp+iZKcnAnwoM_ZJhg@mail.gmail.com","subject":"Re: [PATCH] compat/regex: fix compilation on Windows","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2017-05-15T01:39:01Z","receivedAt":"2017-05-15T01:39:10Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ævar Arnfjörð Bjarmason writes:\n\n> Let's drop this current gawk import series.\n>\n> After talking to the gawk author it turns out it's better to use the\n> version from gnulib, this includes the equivalent of your patch.\n\nOK. That may make things simpler ;-)\n\nThanks.\n"}]}