{"thread":{"id":"8356","subject":"[PATCH] Introduce git-supported-features for porcelain use","startedAt":"2007-05-30T04:31:13Z","lastAt":"2007-06-01T07:13:57Z","messageCount":12,"participants":["Shawn O. Pearce","Alex Riesen","Johannes Schindelin","Junio C Hamano","Johannes Sixt"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"43610","messageId":"20070530043113.GA12300@spearce.org","threadId":"8356","inReplyTo":null,"subject":"[PATCH] Introduce git-supported-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-30T04:31:13Z","receivedAt":"2007-05-30T04:31:13Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"As a porcelain author I'm finding it difficult to keep track of\nwhat features I can use in git-gui.  Newer versions of Git have\nnewer capabilities but they don't always immediately get newer\nversion numbers that I can easily test for.\n\nThis is a simple plumbing command that lets a porcelain ask the\nplumbing for its capabilities, at which point the porcelain can\nwork around anything missing, or recommend to the user that they\nupgrade their plumbing layer.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n .gitignore                               |    1 +\n Documentation/git-supported-features.txt |   37 +++++++++++++++++\n Makefile                                 |    1 +\n builtin-supported-features.c             |   66 ++++++++++++++++++++++++++++++\n builtin.h                                |    1 +\n git.c                                    |    1 +\n t/t0000-basic.sh                         |   10 +++++\n 7 files changed, 117 insertions(+), 0 deletions(-)\n create mode 100644 Documentation/git-supported-features.txt\n create mode 100644 builtin-supported-features.c\n\ndiff --git a/.gitignore b/.gitignore\nindex 4dc0c39..6ff18d4 100644\n--- a/.gitignore\n+++ b/.gitignore\n@@ -126,6 +126,7 @@ git-ssh-push\n git-ssh-upload\n git-status\n git-stripspace\n+git-supported-features\n git-svn\n git-svnimport\n git-symbolic-ref\ndiff --git a/Documentation/git-supported-features.txt b/Documentation/git-supported-features.txt\nnew file mode 100644\nindex 0000000..28e2c21\n--- /dev/null\n+++ b/Documentation/git-supported-features.txt\n@@ -0,0 +1,37 @@\n+git-supported-features(1)\n+===================\n+\n+NAME\n+----\n+git-supported-features - Report capabilities of the plumbing\n+\n+SYNOPSIS\n+--------\n+'git-supported-features' [<name>]\n+\n+DESCRIPTION\n+-----------\n+Given no arguments this plumbing utility displays a list of feature\n+strings, one per line, that this particular version of the Git\n+plumbing supports.  These strings can be matched by higher level\n+porcelain to determine what capabilities are available to its use.\n+\n+Given one argument (the name of the feature to test) the program\n+exits with 0 if the feature is supported, and 1 if it is not.\n+Other exit codes are undefined at this time.\n+\n+NOTES\n+-----\n+The exact list of feature strings is undefined by this manual page.\n+\n+Feature strings use a restricted character set, relying only on\n+`a`-`z` (lowercase), `0`-`9` and `-` (hypen).  This restriction is\n+intentional, as it makes parsing output in shell quite simple.\n+\n+Author\n+------\n+Written by Shawn O. Pearce <spearce@spearce.org>.\n+\n+GIT\n+---\n+Part of the gitlink:git[7] suite\ndiff --git a/Makefile b/Makefile\nindex 7527734..03ab471 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -372,6 +372,7 @@ BUILTIN_OBJS = \\\n \tbuiltin-shortlog.o \\\n \tbuiltin-show-branch.o \\\n \tbuiltin-stripspace.o \\\n+\tbuiltin-supported-features.o \\\n \tbuiltin-symbolic-ref.o \\\n \tbuiltin-tar-tree.o \\\n \tbuiltin-unpack-objects.o \\\ndiff --git a/builtin-supported-features.c b/builtin-supported-features.c\nnew file mode 100644\nindex 0000000..79007f4\n--- /dev/null\n+++ b/builtin-supported-features.c\n@@ -0,0 +1,66 @@\n+#include \"builtin.h\"\n+\n+static const char *features[] = {\n+\t\"git-k\",\n+\t\"redirect-stderr\",\n+\t\"supported-features\",\n+};\n+\n+static int is_sane(const char *a)\n+{\n+\tif (!*a || *a == '-')\n+\t\treturn 0;\n+\tfor (; *a; a++) {\n+\t\tif (! ((*a >= 'a' && *a <= 'z')\n+\t\t    || (*a >= '0' && *a <= '9')\n+\t\t    || *a == '-'))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static int sort_feature(const void *a_, const void *b_)\n+{\n+\tconst char *a = *((const char **)a_);\n+\tconst char *b = *((const char **)b_);\n+\treturn strcmp(a, b);\n+}\n+\n+static void list_features()\n+{\n+\tunsigned cnt = ARRAY_SIZE(features);\n+\tunsigned i;\n+\n+\tqsort(features, cnt, sizeof(features[0]), sort_feature);\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tif (!is_sane(features[i]))\n+\t\t\tdie(\"feature name \\\"%s\\\" is bogus\", features[i]);\n+\t\tprintf(\"%s\\n\", features[i]);\n+\t}\n+}\n+\n+static int test_feature(const char *the_feature)\n+{\n+\tunsigned cnt = ARRAY_SIZE(features);\n+\tunsigned i;\n+\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tif (!strcmp(features[i], the_feature))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static const char supported_features_usage[] =\n+\"git-supported-features [<feature>]\";\n+\n+int cmd_supported_features(int argc, const char **argv, const char *prefix)\n+{\n+\tif (argc == 1)\n+\t\tlist_features();\n+\telse if (argc == 2)\n+\t\treturn test_feature(argv[1]);\n+\telse\n+\t\tusage(supported_features_usage);\n+\treturn 0;\n+}\ndiff --git a/builtin.h b/builtin.h\nindex 39290d1..f33432c 100644\n--- a/builtin.h\n+++ b/builtin.h\n@@ -71,6 +71,7 @@ extern int cmd_shortlog(int argc, const char **argv, const char *prefix);\n extern int cmd_show(int argc, const char **argv, const char *prefix);\n extern int cmd_show_branch(int argc, const char **argv, const char *prefix);\n extern int cmd_stripspace(int argc, const char **argv, const char *prefix);\n+extern int cmd_supported_features(int argc, const char **argv, const char *prefix);\n extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);\n extern int cmd_tar_tree(int argc, const char **argv, const char *prefix);\n extern int cmd_unpack_objects(int argc, const char **argv, const char *prefix);\ndiff --git a/git.c b/git.c\nindex 29b55a1..377fae9 100644\n--- a/git.c\n+++ b/git.c\n@@ -284,6 +284,7 @@ static void handle_internal_command(int argc, const char **argv, char **envp)\n \t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n \t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n \t\t{ \"stripspace\", cmd_stripspace },\n+\t\t{ \"supported-features\", cmd_supported_features },\n \t\t{ \"symbolic-ref\", cmd_symbolic_ref, RUN_SETUP },\n \t\t{ \"tar-tree\", cmd_tar_tree },\n \t\t{ \"unpack-objects\", cmd_unpack_objects, RUN_SETUP },\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 186de70..7d0d9c9 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -31,6 +31,16 @@ fi\n . ./test-lib.sh\n \n ################################################################\n+# git-supported-features should always work.\n+\n+test_expect_success \\\n+\t'supported-features is functional' \\\n+\t'git-supported-features'\n+test_expect_success \\\n+\t'supported-features recognizes itself' \\\n+\t'git-supported-features supported-features'\n+\n+################################################################\n # git-init has been done in an empty repository.\n # make sure it is empty.\n \n-- \n1.5.2.869.g6b3ba\n"},{"id":"43629","messageId":"81b0412b0705300504h24c4c32ew8460dede4aeffd52@mail.gmail.com","threadId":"8356","inReplyTo":"20070530043113.GA12300@spearce.org","subject":"Re: [PATCH] Introduce git-supported-features for porcelain use","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-30T12:04:06Z","receivedAt":"2007-05-30T12:04:06Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/30/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> As a porcelain author I'm finding it difficult to keep track of\n> what features I can use in git-gui.  Newer versions of Git have\n> newer capabilities but they don't always immediately get newer\n> version numbers that I can easily test for.\n\ngit-version --features?\n"},{"id":"43631","messageId":"Pine.LNX.4.64.0705301333410.4011@racer.site","threadId":"8356","inReplyTo":"81b0412b0705300504h24c4c32ew8460dede4aeffd52@mail.gmail.com","subject":"Re: [PATCH] Introduce git-supported-features for porcelain use","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-30T12:34:57Z","receivedAt":"2007-05-30T12:34:57Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 May 2007, Alex Riesen wrote:\n\n> On 5/30/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> > As a porcelain author I'm finding it difficult to keep track of\n> > what features I can use in git-gui.  Newer versions of Git have\n> > newer capabilities but they don't always immediately get newer\n> > version numbers that I can easily test for.\n> \n> git-version --features?\n\nMelikes. (Even if it is not strictly separating between plumbing and \nporcelain; I consider git-version porcelain...)\n\nCiao,\nDscho\n"},{"id":"43666","messageId":"20070531002030.GA15714@spearce.org","threadId":"8356","inReplyTo":"Pine.LNX.4.64.0705301333410.4011@racer.site","subject":"[PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-31T00:20:30Z","receivedAt":"2007-05-31T00:20:30Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"As a porcelain author I'm finding it difficult to keep track of\nwhat features I can use in git-gui.  Newer versions of Git have\nnewer capabilities but they don't always immediately get newer\nversion numbers that I can easily test for.\n\nThis is a simple plumbing option that lets a porcelain ask the\nplumbing for its capabilities, at which point the porcelain can\nwork around anything missing, or recommend to the user that they\nupgrade their plumbing layer.\n\nSigned-off-by: Shawn O. Pearce <spearce@spearce.org>\n---\n\n\tJohannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n\t>\n\t> On Wed, 30 May 2007, Alex Riesen wrote:\n\t>\n\t> > git-version --features?\n\t>\n\t> Melikes.\n\n\tGood?\n\n help.c           |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++++-\n t/t0000-basic.sh |   16 +++++++++++\n 2 files changed, 92 insertions(+), 2 deletions(-)\n\ndiff --git a/help.c b/help.c\nindex 6a9af4d..9d9cccd 100644\n--- a/help.c\n+++ b/help.c\n@@ -9,6 +9,12 @@\n #include \"common-cmds.h\"\n #include <sys/ioctl.h>\n \n+static const char *supported_features[] = {\n+\t\"git-k\",\n+\t\"list-features\",\n+\t\"redirect-stderr\",\n+};\n+\n /* most GUI terminals set COLUMNS (although some don't export it) */\n static int term_columns(void)\n {\n@@ -190,10 +196,78 @@ void help_unknown_cmd(const char *cmd)\n \texit(1);\n }\n \n+static int is_feature_name_sane(const char *a)\n+{\n+\tif (!*a || *a == '-')\n+\t\treturn 0;\n+\tfor (; *a; a++) {\n+\t\tif (! ((*a >= 'a' && *a <= 'z')\n+\t\t    || (*a >= '0' && *a <= '9')\n+\t\t    || *a == '-'))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static int cmp_feature(const void *a_, const void *b_)\n+{\n+\tconst char *a = *((const char **)a_);\n+\tconst char *b = *((const char **)b_);\n+\treturn strcmp(a, b);\n+}\n+\n+static void list_features()\n+{\n+\tunsigned cnt = ARRAY_SIZE(supported_features);\n+\tunsigned i;\n+\n+\tqsort(supported_features, cnt,\n+\t\tsizeof(supported_features[0]), cmp_feature);\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tconst char *f = supported_features[i];\n+\t\tif (!is_feature_name_sane(f))\n+\t\t\tdie(\"feature name \\\"%s\\\" is bogus\", f);\n+\t\tprintf(\"%s\\n\", f);\n+\t}\n+}\n+\n+static int supports_feature(const char *the_feature)\n+{\n+\tunsigned cnt = ARRAY_SIZE(supported_features);\n+\tunsigned i;\n+\n+\tfor (i = 0; i < cnt; i++) {\n+\t\tif (!strcmp(supported_features[i], the_feature))\n+\t\t\treturn 0;\n+\t}\n+\treturn 1;\n+}\n+\n+static const char version_usage[] =\n+\"git-version [(--list-features | --supports-feature=<name>*)]\";\n+\n int cmd_version(int argc, const char **argv, const char *prefix)\n {\n-\tprintf(\"git version %s\\n\", git_version_string);\n-\treturn 0;\n+\tint i, ret = 0, list = 0, test = 0;\n+\n+\tfor (i = 1; i < argc; i++) {\n+\t\tconst char *arg = argv[i];\n+\t\tif (!strcmp(arg, \"--list-features\"))\n+\t\t\tlist = 1;\n+\t\telse if (!prefixcmp(arg, \"--supports-feature=\")) {\n+\t\t\ttest = 1;\n+\t\t\tret |= supports_feature(arg + 19);\n+\t\t} else\n+\t\t\tusage(version_usage);\n+\t}\n+\n+\tif (list && test)\n+\t\tdie(\"cannot use both --list-features and --supports-feature\");\n+\tif (list)\n+\t\tlist_features();\n+\tif (!list && !test)\n+\t\tprintf(\"git version %s\\n\", git_version_string);\n+\treturn ret;\n }\n \n int cmd_help(int argc, const char **argv, const char *prefix)\ndiff --git a/t/t0000-basic.sh b/t/t0000-basic.sh\nindex 186de70..874bb04 100755\n--- a/t/t0000-basic.sh\n+++ b/t/t0000-basic.sh\n@@ -31,6 +31,22 @@ fi\n . ./test-lib.sh\n \n ################################################################\n+# git version\n+\n+test_expect_success \\\n+\t'git version is functional' \\\n+\t'git version'\n+test_expect_success \\\n+\t'git version --list-features' \\\n+\t'git version --list-features'\n+test_expect_success \\\n+\t'feature \"list-features\" is supported' \\\n+\t'git version --supports-feature=list-features'\n+test_expect_failure \\\n+\t'feature \"THISNEVERWILLBEAGITFEATURE\" is not supported' \\\n+\t'git version --supports-feature=THISNEVERWILLBEAGITFEATURE'\n+\n+################################################################\n # git-init has been done in an empty repository.\n # make sure it is empty.\n \n-- \n1.5.2.869.g6b3ba\n"},{"id":"43668","messageId":"Pine.LNX.4.64.0705310125160.4046@racer.site","threadId":"8356","inReplyTo":"20070531002030.GA15714@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-05-31T00:25:49Z","receivedAt":"2007-05-31T00:25:49Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 30 May 2007, Shawn O. Pearce wrote:\n\n> \tJohannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \t>\n> \t> On Wed, 30 May 2007, Alex Riesen wrote:\n> \t>\n> \t> > git-version --features?\n> \t>\n> \t> Melikes.\n> \n> \tGood?\n\nYep. No more complaints from my side.\n\nCiao,\nDscho\n"},{"id":"43678","messageId":"81b0412b0705302350i3ebf48e8h24537c20a413e709@mail.gmail.com","threadId":"8356","inReplyTo":"20070531002030.GA15714@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Alex Riesen","fromEmail":"raa.lkml@gmail.com","sentAt":"2007-05-31T06:50:16Z","receivedAt":"2007-05-31T06:50:16Z","isPatch":true,"sender":{"key":"raa.lkml@gmail.com","avatar":"https://avatars.githubusercontent.com/u/324101?v=4"},"body":"On 5/31/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> >\n> > On Wed, 30 May 2007, Alex Riesen wrote:\n> >\n> > > git-version --features?\n> >\n> > Melikes.\n>\n> Good?\n>\n\nWas just a suggestion. Good.\n"},{"id":"43685","messageId":"20070531133011.GW7044@spearce.org","threadId":"8356","inReplyTo":"81b0412b0705302350i3ebf48e8h24537c20a413e709@mail.gmail.com","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-05-31T13:30:11Z","receivedAt":"2007-05-31T13:30:11Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Alex Riesen <raa.lkml@gmail.com> wrote:\n> On 5/31/07, Shawn O. Pearce <spearce@spearce.org> wrote:\n> >Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> >>\n> >> On Wed, 30 May 2007, Alex Riesen wrote:\n> >>\n> >> > git-version --features?\n> >>\n> >> Melikes.\n> >\n> >Good?\n> >\n> \n> Was just a suggestion. Good.\n\nWell, a quick poll on IRC seemed to get like 5 additional votes for\nthis being a switch on git-version.  That sealed the deal.  I wasn't\ncommitted one way or the other.  I just wanted the functionality...\n\nAlso votes from you and Dscho carry a little weight around here.  :-)\n\n-- \nShawn.\n"},{"id":"43706","messageId":"7vk5uo1rpr.fsf@assigned-by-dhcp.cox.net","threadId":"8356","inReplyTo":"20070531002030.GA15714@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-05-31T23:46:56Z","receivedAt":"2007-05-31T23:46:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> As a porcelain author I'm finding it difficult to keep track of\n> what features I can use in git-gui.  Newer versions of Git have\n> newer capabilities but they don't always immediately get newer\n> version numbers that I can easily test for.\n>\n> This is a simple plumbing option that lets a porcelain ask the\n> plumbing for its capabilities, at which point the porcelain can\n> work around anything missing, or recommend to the user that they\n> upgrade their plumbing layer.\n>\n> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>\n> ---\n>\n> \tJohannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> \t>\n> \t> On Wed, 30 May 2007, Alex Riesen wrote:\n> \t>\n> \t> > git-version --features?\n> \t>\n> \t> Melikes.\n>\n> \tGood?\n\nHmmm.  I am not sure if you want list-features in the features\nlist -- how are you going to test for it?\n\nAlso I still do not understand why you want redirect-stderr.\nAre you writing for a shell-less environment?\n"},{"id":"43714","messageId":"20070601030959.GY7044@spearce.org","threadId":"8356","inReplyTo":"7vk5uo1rpr.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-01T03:09:59Z","receivedAt":"2007-06-01T03:09:59Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> \"Shawn O. Pearce\" <spearce@spearce.org> writes:\n> \n> > As a porcelain author I'm finding it difficult to keep track of\n> > what features I can use in git-gui.  Newer versions of Git have\n> > newer capabilities but they don't always immediately get newer\n> > version numbers that I can easily test for.\n> >\n> > This is a simple plumbing option that lets a porcelain ask the\n> > plumbing for its capabilities, at which point the porcelain can\n> > work around anything missing, or recommend to the user that they\n> > upgrade their plumbing layer.\n> >\n> > Signed-off-by: Shawn O. Pearce <spearce@spearce.org>\n> > ---\n> >\n> > \tJohannes Schindelin <Johannes.Schindelin@gmx.de> wrote:\n> > \t>\n> > \t> On Wed, 30 May 2007, Alex Riesen wrote:\n> > \t>\n> > \t> > git-version --features?\n> > \t>\n> > \t> Melikes.\n> >\n> > \tGood?\n> \n> Hmmm.  I am not sure if you want list-features in the features\n> list -- how are you going to test for it?\n\nYes, its a recursive definition.  But its also a feature that won't\never be removed; if list-features is here then the list-features\nfeature is also here.  Makes the test in t0000 a lot easier, and\nits not a huge deal to say \"yes, the feature that i implement is\nhere too\".  ;-)\n \n> Also I still do not understand why you want redirect-stderr.\n> Are you writing for a shell-less environment?\n\nThe redirect-stderr thing grew out of the MinGW port camp.\nApparently they cannot use (or its hard to use) an important little\ntool called `cat` over there.\n\nWhy cat?  Tcl is so horribly broken that to get data for both stdout\nand stderr through a pipe I have to do something sick like:\n\n\tgit fetch 2>&1 | cat\n\nbecause in Tcl its actually:\n\n\tset rdr [open \"| git fetch |& cat\" r]\n\nThe |& means 2>&1| in normal shell.  But that means I have to have\na process after it to receive the data.  Normally that's cat.\nBut MinGW doesn't have cat.  (Nor do they have dog, but neither\ndoes Linux...).  So I need a way to redirect output.\n\nDscho's patch to git.c to give me `git --redirect-stderr` is quite\nsimple, and makes my life in git-gui easier.  I can just require\nthat to use git-gui on MinGW you must have the 'redirect-stderr'\nfeature supported in your plumbing layer.  On non-MinGW systems I\ncan fallback to \"&| cat\" if its not supported.\n\n-- \nShawn.\n"},{"id":"43717","messageId":"7vvee8z5q9.fsf@assigned-by-dhcp.cox.net","threadId":"8356","inReplyTo":"20070601030959.GY7044@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-06-01T03:57:50Z","receivedAt":"2007-06-01T03:57:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Shawn O. Pearce\" <spearce@spearce.org> writes:\n\n> Why cat?  Tcl is so horribly broken that to get data for both stdout\n> and stderr through a pipe I have to do something sick like:\n>\n> \tgit fetch 2>&1 | cat\n>\n> because in Tcl its actually:\n>\n> \tset rdr [open \"| git fetch |& cat\" r]\n>\n> The |& means 2>&1| in normal shell.  But that means I have to have\n> a process after it to receive the data.  Normally that's cat.\n> But MinGW doesn't have cat.  (Nor do they have dog, but neither\n> does Linux...).  So I need a way to redirect output.\n\nWait a minute.  Who interprets |& in the above?  Isn't it a\nshell?\n\nThat's why I asked if you are writing for shell-less\nenvironment.  If you are _not_, can't you do something like this\ninstead?\n\n\tset rdr [open \"| sh -c 'git fetch 2>&1'\" r]\n\nthat is, instead of running a command called \"git\", you invoke a\ncommand called \"sh\" with two parameters, the second parameter\nbeing a tad long string that happens to have three letter\nsequence '2>&1' in it.\n"},{"id":"43718","messageId":"20070601041458.GC7044@spearce.org","threadId":"8356","inReplyTo":"7vvee8z5q9.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2007-06-01T04:14:58Z","receivedAt":"2007-06-01T04:14:58Z","isPatch":true,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano <junkio@cox.net> wrote:\n> \"Shawn O. Pearce\" <spearce@spearce.org> writes:\n> \n> > Why cat?  Tcl is so horribly broken that to get data for both stdout\n> > and stderr through a pipe I have to do something sick like:\n> >\n> > \tgit fetch 2>&1 | cat\n> >\n> > because in Tcl its actually:\n> >\n> > \tset rdr [open \"| git fetch |& cat\" r]\n> >\n> > The |& means 2>&1| in normal shell.  But that means I have to have\n> > a process after it to receive the data.  Normally that's cat.\n> > But MinGW doesn't have cat.  (Nor do they have dog, but neither\n> > does Linux...).  So I need a way to redirect output.\n> \n> Wait a minute.  Who interprets |& in the above?  Isn't it a\n> shell?\n\nMy understanding was it is Tcl itself.  My $SHELL doesn't understand\nit:\n\n  $ echo hi |& cat\n  -bash: syntax error near unexpected token `&'\n\n> That's why I asked if you are writing for shell-less\n> environment.  If you are _not_, can't you do something like this\n> instead?\n\nIdeally with MinGW we wouldn't need a UNIX shell to get things\nworking in git-gui.  But we have to have one for git-merge for\nexample, as git-gui doesn't have a builtin Grand Unified Merge\nDriver.  Also for git-fetch, which is one of the prime uses of this\ncat redirect thing.  ;-)\n\n> \tset rdr [open \"| sh -c 'git fetch 2>&1'\" r]\n\nYeah, I'm already doing that sh -c trick for a different reason in\nanother context.  I may have to do just that here too.\n\n-- \nShawn.\n"},{"id":"43721","messageId":"465FC735.C78ACD5@eudaptics.com","threadId":"8356","inReplyTo":"20070601030959.GY7044@spearce.org","subject":"Re: [PATCH] Introduce git version --list-features for porcelain use","fromName":"Johannes Sixt","fromEmail":"j.sixt@eudaptics.com","sentAt":"2007-06-01T07:13:57Z","receivedAt":"2007-06-01T07:13:57Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"\"Shawn O. Pearce\" wrote:\n> Why cat?  Tcl is so horribly broken that to get data for both stdout\n> and stderr through a pipe I have to do something sick like:\n> \n>         git fetch 2>&1 | cat\n> \n> because in Tcl its actually:\n> \n>         set rdr [open \"| git fetch |& cat\" r]\n> \n> The |& means 2>&1| in normal shell.  But that means I have to have\n> a process after it to receive the data.  Normally that's cat.\n> But MinGW doesn't have cat.  (Nor do they have dog, but neither\n> does Linux...).  So I need a way to redirect output.\n\nAre you planning for the future? Currently, the MinGW port works only\nwith MSYS installed and $MSYS/bin in your PATH because the shell scripts\nneed an assorted set of POSIX tools. MSYS does ship 'cat', of course.\n\n-- Hannes\n"}]}