{"thread":{"id":"21761","subject":"[RFC/PATCH 0/2] status -s: Use the same config as status","startedAt":"2009-11-26T15:24:37Z","lastAt":"2009-11-27T09:22:12Z","messageCount":14,"participants":["Michael J Gruber","Johannes Sixt","Junio C Hamano","Jeff King"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"128467","messageId":"cover.1259248243.git.git@drmicha.warpmail.net","threadId":"21761","inReplyTo":null,"subject":"[RFC/PATCH 0/2] status -s: Use the same config as status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-26T15:24:37Z","receivedAt":"2009-11-26T15:24:37Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"This mini series is an RFC for bringing the short version of status in line\nwith the longer one. They already both obey status.showUntrackedFiles.\nCurrently, status -s does not obey status.relativePaths nor\ncolor.status.\n\nI think status should follow the priniciple of least surprise here in\nthe sense that -s should not change other aspects of the output\n(although it is very different internally).\n\nI think we don't have any tests for status -s yet, which is one reason\nwhy this is an RFC: I don't expect to get through with it, like the\nintroducer of status -s did ;) Another reason is mentioned in 2/2.\n\nMichael J Gruber (2):\n status -s: respect the status.relativePaths option\n status -s: obey color.status\n\n builtin-commit.c | 22 +++++++++++++++++-----\n wt-status.c | 2 +-\n wt-status.h | 1 +\n 3 files changed, 19 insertions(+), 6 deletions(-)\n"},{"id":"128468","messageId":"62c5bb36940485deefbf73f4bdc3fd45bbea069e.1259248243.git.git@drmicha.warpmail.net","threadId":"21761","inReplyTo":"cover.1259248243.git.git@drmicha.warpmail.net","subject":"[RFC/PATCH 1/2] status -s: respect the status.relativePaths option","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-26T15:24:38Z","receivedAt":"2009-11-26T15:24:38Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"so that 'status' and 'status -s' in a subdir produce the same file\nnames.\n\nSigned-off-by: Michael J Gruber \n---\nAnything else would be highly surprising. Note that the porcelain case\nis unchanged, of course.\n\n builtin-commit.c | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 7f888fe..c103beb 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -1113,6 +1113,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \n \tswitch (status_format) {\n \tcase STATUS_FORMAT_SHORT:\n+\t\tif (s.relative_paths)\n+\t\t\ts.prefix = prefix;\n \t\tshort_print(&s, null_termination);\n \t\tbreak;\n \tcase STATUS_FORMAT_PORCELAIN:\n-- \n1.6.6.rc0.274.g71380\n"},{"id":"128469","messageId":"26d0a2022638ad7b75268ca291b8d02a22f1f66c.1259248243.git.git@drmicha.warpmail.net","threadId":"21761","inReplyTo":"cover.1259248243.git.git@drmicha.warpmail.net","subject":"[RFC/PATCH 2/2] status -s: obey color.status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-26T15:24:39Z","receivedAt":"2009-11-26T15:24:39Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Make the short version of status obey the color.status boolean. We color\nthe status letters only, because they carry the state information and are\npotentially colored differently, such as for a file with staged changes\nas well as changes in the worktree against the index.\n\nSigned-off-by: Michael J Gruber \n---\nThis is RFC for several reasons:\n\n* Should I rename wt-status.c's color() into something more unique when\n I export it?\n* Is there any policy regarding use of putchar/puts vs. printf?\n* The way it is done now I \"color\" a space, otherwise one would need to\n break down the print statements even more. Since we always color the\n foreground only it is no problem, is it?\n* Even if I were to write tests for status -s: How do I test colors?\n\n builtin-commit.c | 20 +++++++++++++++-----\n wt-status.c | 2 +-\n wt-status.h | 1 +\n 3 files changed, 17 insertions(+), 6 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex c103beb..c38fc96 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -999,7 +999,7 @@ static void short_unmerged(int null_termination, struct string_list_item *it,\n \tcase 6: how = \"AA\"; break; /* both added */\n \tcase 7: how = \"UU\"; break; /* both modified */\n \t}\n-\tprintf(\"%s \", how);\n+\tcolor_fprintf(s->fp, color(WT_STATUS_UNMERGED, s), \"%s \", how);\n \tif (null_termination) {\n \t\tfprintf(stdout, \"%s%c\", it->string, 0);\n \t} else {\n@@ -1016,9 +1016,14 @@ static void short_status(int null_termination, struct string_list_item *it,\n {\n \tstruct wt_status_change_data *d = it->util;\n \n-\tprintf(\"%c%c \",\n-\t !d->index_status ? ' ' : d->index_status,\n-\t !d->worktree_status ? ' ' : d->worktree_status);\n+\tif (d->index_status)\n+\t\tcolor_fprintf(s->fp, color(WT_STATUS_UPDATED, s), \"%c\", d->index_status);\n+\telse\n+\t\tputchar(' ');\n+\tif (d->worktree_status)\n+\t\tcolor_fprintf(s->fp, color(WT_STATUS_CHANGED, s), \"%c \", d->worktree_status);\n+\telse\n+\t\tprintf(\" \");\n \tif (null_termination) {\n \t\tfprintf(stdout, \"%s%c\", it->string, 0);\n \t\tif (d->head_path)\n@@ -1046,7 +1051,8 @@ static void short_untracked(int null_termination, struct string_list_item *it,\n \t\tstruct strbuf onebuf = STRBUF_INIT;\n \t\tconst char *one;\n \t\tone = quote_path(it->string, -1, &onebuf, s->prefix);\n-\t\tprintf(\"?? %s\\n\", one);\n+\t\tcolor_fprintf(s->fp, color(WT_STATUS_UNTRACKED, s), \"?? \");\n+\t\tputs(one);\n \t\tstrbuf_release(&onebuf);\n \t}\n }\n@@ -1115,6 +1121,10 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \tcase STATUS_FORMAT_SHORT:\n \t\tif (s.relative_paths)\n \t\t\ts.prefix = prefix;\n+\t\tif (s.use_color == -1)\n+\t\t\ts.use_color = git_use_color_default;\n+\t\tif (diff_use_color_default == -1)\n+\t\t\tdiff_use_color_default = git_use_color_default;\n \t\tshort_print(&s, null_termination);\n \t\tbreak;\n \tcase STATUS_FORMAT_PORCELAIN:\ndiff --git a/wt-status.c b/wt-status.c\nindex 3c2f580..c779b7c 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -19,7 +19,7 @@ static char default_wt_status_colors[][COLOR_MAXLEN] = {\n \tGIT_COLOR_RED, /* WT_STATUS_UNMERGED */\n };\n \n-static const char *color(int slot, struct wt_status *s)\n+const char *color(int slot, struct wt_status *s)\n {\n \treturn s->use_color > 0 ? s->color_palette[slot] : \"\";\n }\ndiff --git a/wt-status.h b/wt-status.h\nindex 09fd9f1..22b15b0 100644\n--- a/wt-status.h\n+++ b/wt-status.h\n@@ -55,5 +55,6 @@ struct wt_status {\n void wt_status_prepare(struct wt_status *s);\n void wt_status_print(struct wt_status *s);\n void wt_status_collect(struct wt_status *s);\n+const char *color(int slot, struct wt_status *s);\n \n #endif /* STATUS_H */\n-- \n1.6.6.rc0.274.g71380\n"},{"id":"128471","messageId":"4B0EA06A.1050101@viscovery.net","threadId":"21761","inReplyTo":"26d0a2022638ad7b75268ca291b8d02a22f1f66c.1259248243.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH 2/2] status -s: obey color.status","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-26T15:36:10Z","receivedAt":"2009-11-26T15:36:10Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Michael J Gruber schrieb:\n> * Is there any policy regarding use of putchar/puts vs. printf?\n\nIf the printed string contains color escapes that should be obeyed, you\ncan use only fputs, printf, and fprintf. You should not use puts or putchar.\n\n> * Even if I were to write tests for status -s: How do I test colors?\n\nSee t4034-diff-words.sh.\n\n-- Hannes\n"},{"id":"128473","messageId":"4B0EA6DF.6070701@drmicha.warpmail.net","threadId":"21761","inReplyTo":"4B0EA06A.1050101@viscovery.net","subject":"Re: [RFC/PATCH 2/2] status -s: obey color.status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-26T16:03:43Z","receivedAt":"2009-11-26T16:03:43Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 26.11.2009 16:36:\n> Michael J Gruber schrieb:\n>> * Is there any policy regarding use of putchar/puts vs. printf?\n> \n> If the printed string contains color escapes that should be obeyed, you\n> can use only fputs, printf, and fprintf. You should not use puts or putchar.\n\nOh, I don't use them with colors. I use only color_fprintf for that. I\nwas wondering whether there's a preference of printf(\"%c\", c) over\nputchar(c), for example.\n\n>> * Even if I were to write tests for status -s: How do I test colors?\n> \n> See t4034-diff-words.sh.\n\nThanks, I'll keep that in mind for the case that I do have to write test ;)\n\nMichael\n"},{"id":"128488","messageId":"7vy6lt6rh3.fsf@alter.siamese.dyndns.org","threadId":"21761","inReplyTo":"4B0EA06A.1050101@viscovery.net","subject":"Re: [RFC/PATCH 2/2] status -s: obey color.status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-26T19:00:56Z","receivedAt":"2009-11-26T19:00:56Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Michael J Gruber schrieb:\n>> * Is there any policy regarding use of putchar/puts vs. printf?\n>\n> If the printed string contains color escapes that should be obeyed, you\n> can use only fputs, printf, and fprintf. You should not use puts or putchar.\n\nThis msysgit-imposed restriction is something even I do not remember\noffhand. Could you please document it somewhere in a file any developer\nwould get by checking out the 'master' branch of git.git?\n"},{"id":"128523","messageId":"7vljhsy7x4.fsf@alter.siamese.dyndns.org","threadId":"21761","inReplyTo":"62c5bb36940485deefbf73f4bdc3fd45bbea069e.1259248243.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH 1/2] status -s: respect the status.relativePaths option","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T03:15:51Z","receivedAt":"2009-11-27T03:15:51Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> so that 'status' and 'status -s' in a subdir produce the same file\n> names.\n\nThis configuration is on by default which makes this change even more\nimportant.\n\nI'd squash this in and queue it at the tip of jk/1.7.0-status topic.\n\nThanks\n\n\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex 58d35fb..b3dfa42 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -114,8 +114,8 @@ compatibility) and `color.status.` configuration variables\n to colorize its output.\n \n If the config variable `status.relativePaths` is set to false, then all\n-paths shown in the long format are relative to the repository root, not\n-to the current directory.\n+paths shown are relative to the repository root, not to the current\n+directory.\n \n If `status.submodulesummary` is set to a non zero number or true (identical\n to -1 or an unlimited number), the submodule summary will be enabled for\n"},{"id":"128525","messageId":"7vws1cwnu0.fsf@alter.siamese.dyndns.org","threadId":"21761","inReplyTo":"26d0a2022638ad7b75268ca291b8d02a22f1f66c.1259248243.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH 2/2] status -s: obey color.status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T05:15:03Z","receivedAt":"2009-11-27T05:15:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Michael J Gruber writes:\n\n> * Should I rename wt-status.c's color() into something more unique when\n> I export it?\n\nIs it an option to instead move short_unmerged(), short_status() and\nfriends to wt-status.c from builtin-commit.c? It's been quite a while\nsince I worked on the code, so I don't recall why it needs such cross\nreferences at low level between two files.\n\n> * Is there any policy regarding use of putchar/puts vs. printf?\n\nJ6t addressed it. You have mixture of putchar(' ') and printf(\" \") which\nlooks somewhat funny ;-)\n\n> * The way it is done now I \"color\" a space, otherwise one would need to\n> break down the print statements even more. Since we always color the\n> foreground only it is no problem, is it?\n\nSome people do configure to use \"reverse\". For example, I have:\n\n [diff.color]\n old = red reverse\n whitespace = blue reverse\n\n [status.color]\n updated = green\n changed = red\n untracked = blue reverse\n\nThe output should be consistent between long and short format (I do not\noffhand recall what we do for the long format, though).\n"},{"id":"128533","messageId":"4B0F78F1.4040101@viscovery.net","threadId":"21761","inReplyTo":"7vy6lt6rh3.fsf@alter.siamese.dyndns.org","subject":"[PATCH] Add a notice that only certain functions can print color escape codes","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-27T07:00:01Z","receivedAt":"2009-11-27T07:00:01Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"From: Johannes Sixt \n\nWe emulate color escape codes on Windows by overriding printf, fprintf,\nand fputs. Warn users that these are the only functions that can be used\nto print them.\n\nSigned-off-by: Johannes Sixt \n---\nJunio C Hamano schrieb:\n> Johannes Sixt writes:\n> \n>> Michael J Gruber schrieb:\n>>> * Is there any policy regarding use of putchar/puts vs. printf?\n>> If the printed string contains color escapes that should be obeyed, you\n>> can use only fputs, printf, and fprintf. You should not use puts or putchar.\n> \n> This msysgit-imposed restriction is something even I do not remember\n> offhand. Could you please document it somewhere in a file any developer\n> would get by checking out the 'master' branch of git.git?\n\nLike this?\n\n color.h | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/color.h b/color.h\nindex 7d8da6f..edeaa3e 100644\n--- a/color.h\n+++ b/color.h\n@@ -4,6 +4,11 @@\n /* \"\\033[1;38;5;2xx;48;5;2xxm\\0\" is 23 bytes */\n #define COLOR_MAXLEN 24\n\n+/*\n+ * IMPORTANT: Due to the way these color codes are emulated on Windows,\n+ * write them only using printf, fprintf, and fputs. In particular,\n+ * do not use puts.\n+ */\n #define GIT_COLOR_NORMAL\t\"\"\n #define GIT_COLOR_RESET\t\t\"\\033[m\"\n #define GIT_COLOR_BOLD\t\t\"\\033[1m\"\n-- \n1.6.6.rc0.43.g50037\n"},{"id":"128534","messageId":"20091127070512.GF20844@coredump.intra.peff.net","threadId":"21761","inReplyTo":"62c5bb36940485deefbf73f4bdc3fd45bbea069e.1259248243.git.git@drmicha.warpmail.net","subject":"Re: [RFC/PATCH 1/2] status -s: respect the status.relativePaths option","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-27T07:05:12Z","receivedAt":"2009-11-27T07:05:12Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 26, 2009 at 04:24:38PM +0100, Michael J Gruber wrote:\n\n> so that 'status' and 'status -s' in a subdir produce the same file\n> names.\n\nThanks, I had been meaning to look into this (who knew it would only be\ntwo lines ;) ).\n\nNow that short and porcelain formats are diverging a bit, we should\nprobably have a few tests. I think there may already be a bug in\n\n git commit --dry-run --porcelain\n\nas it looks like commit will use color and relative path configuration\neven for the porcelain version.\n\n-Peff\n"},{"id":"128538","messageId":"7vzl68v2zb.fsf@alter.siamese.dyndns.org","threadId":"21761","inReplyTo":"4B0F78F1.4040101@viscovery.net","subject":"Re: [PATCH] Add a notice that only certain functions can print color escape codes","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-27T07:30:48Z","receivedAt":"2009-11-27T07:30:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Like this?\n\nYeah, and in addition to \"puts\", \"write(2)\" is also not supported, right?\n\n> color.h | 5 +++++\n> 1 files changed, 5 insertions(+), 0 deletions(-)\n>\n> diff --git a/color.h b/color.h\n> index 7d8da6f..edeaa3e 100644\n> --- a/color.h\n> +++ b/color.h\n> @@ -4,6 +4,11 @@\n> /* \"\\033[1;38;5;2xx;48;5;2xxm\\0\" is 23 bytes */\n> #define COLOR_MAXLEN 24\n>\n> +/*\n> + * IMPORTANT: Due to the way these color codes are emulated on Windows,\n> + * write them only using printf, fprintf, and fputs. In particular,\n> + * do not use puts.\n> + */\n> #define GIT_COLOR_NORMAL\t\"\"\n> #define GIT_COLOR_RESET\t\t\"\\033[m\"\n> #define GIT_COLOR_BOLD\t\t\"\\033[1m\"\n> -- \n> 1.6.6.rc0.43.g50037\n"},{"id":"128539","messageId":"4B0F82E1.80402@viscovery.net","threadId":"21761","inReplyTo":"7vzl68v2zb.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] Add a notice that only certain functions can print color escape codes","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2009-11-27T07:42:25Z","receivedAt":"2009-11-27T07:42:25Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Junio C Hamano schrieb:\n> Johannes Sixt writes:\n> \n>> Like this?\n> \n> Yeah, and in addition to \"puts\", \"write(2)\" is also not supported, right?\n\nCorrect, good catch!\n\n--- 8< ---\nFrom: Johannes Sixt \nSubject: [PATCH] Add a notice that only certain functions can print color escape codes\n\nWe emulate color escape codes on Windows by overriding printf, fprintf,\nand fputs. Warn users that these are the only functions that can be used\nto print them.\n\nSigned-off-by: Johannes Sixt \n---\n color.h | 5 +++++\n 1 files changed, 5 insertions(+), 0 deletions(-)\n\ndiff --git a/color.h b/color.h\nindex 7d8da6f..3cb4b7f 100644\n--- a/color.h\n+++ b/color.h\n@@ -4,6 +4,11 @@\n /* \"\\033[1;38;5;2xx;48;5;2xxm\\0\" is 23 bytes */\n #define COLOR_MAXLEN 24\n\n+/*\n+ * IMPORTANT: Due to the way these color codes are emulated on Windows,\n+ * write them only using printf(), fprintf(), and fputs(). In particular,\n+ * do not use puts() or write().\n+ */\n #define GIT_COLOR_NORMAL\t\"\"\n #define GIT_COLOR_RESET\t\t\"\\033[m\"\n #define GIT_COLOR_BOLD\t\t\"\\033[1m\"\n-- \n1.6.6.rc0.43.g50037\n"},{"id":"128549","messageId":"4B0F990C.2010805@drmicha.warpmail.net","threadId":"21761","inReplyTo":"7vws1cwnu0.fsf@alter.siamese.dyndns.org","subject":"Re: [RFC/PATCH 2/2] status -s: obey color.status","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-27T09:17:00Z","receivedAt":"2009-11-27T09:17:00Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Junio C Hamano venit, vidit, dixit 27.11.2009 06:15:\n> Michael J Gruber writes:\n> \n>> * Should I rename wt-status.c's color() into something more unique when\n>> I export it?\n> \n> Is it an option to instead move short_unmerged(), short_status() and\n> friends to wt-status.c from builtin-commit.c? It's been quite a while\n> since I worked on the code, so I don't recall why it needs such cross\n> references at low level between two files.\n\nI didn't notice, but I'll look into it during the rewrite.\n\n>> * Is there any policy regarding use of putchar/puts vs. printf?\n> \n> J6t addressed it. You have mixture of putchar(' ') and printf(\" \") which\n> looks somewhat funny ;-)\n\n;) I'm happy with printf(\"c\"), I just thought someone would find printf\noverkill for a format less char.\n\n>> * The way it is done now I \"color\" a space, otherwise one would need to\n>> break down the print statements even more. Since we always color the\n>> foreground only it is no problem, is it?\n> \n> Some people do configure to use \"reverse\". For example, I have:\n> \n> [diff.color]\n> old = red reverse\n> whitespace = blue reverse\n> \n> [status.color]\n> updated = green\n> changed = red\n> untracked = blue reverse\n> \n> The output should be consistent between long and short format (I do not\n> offhand recall what we do for the long format, though).\n\nOh, I didn't know about reverse. In this case I have to change the code\nand leave the space alone. (The one between ?? and the filename.) Will do.\n\nIn the long format, only the file name is colored. Note that in the\nshort format, it does not make sense to color the file name because one\nline may represent two pieces of status information. That is why I color\nthe two status letters and not the file name.\n\nMichael\n"},{"id":"128550","messageId":"4B0F9A44.7060706@drmicha.warpmail.net","threadId":"21761","inReplyTo":"4B0F82E1.80402@viscovery.net","subject":"Re: [PATCH] Add a notice that only certain functions can print color escape codes","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2009-11-27T09:22:12Z","receivedAt":"2009-11-27T09:22:12Z","isPatch":true,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Sixt venit, vidit, dixit 27.11.2009 08:42:\n> Junio C Hamano schrieb:\n>> Johannes Sixt writes:\n>>\n>>> Like this?\n>>\n>> Yeah, and in addition to \"puts\", \"write(2)\" is also not supported, right?\n> \n> Correct, good catch!\n> \n> --- 8< ---\n> From: Johannes Sixt \n> Subject: [PATCH] Add a notice that only certain functions can print color escape codes\n> \n> We emulate color escape codes on Windows by overriding printf, fprintf,\n> and fputs. Warn users that these are the only functions that can be used\n> to print them.\n> \n> Signed-off-by: Johannes Sixt \n> ---\n> color.h | 5 +++++\n> 1 files changed, 5 insertions(+), 0 deletions(-)\n> \n> diff --git a/color.h b/color.h\n> index 7d8da6f..3cb4b7f 100644\n> --- a/color.h\n> +++ b/color.h\n> @@ -4,6 +4,11 @@\n> /* \"\\033[1;38;5;2xx;48;5;2xxm\\0\" is 23 bytes */\n> #define COLOR_MAXLEN 24\n> \n> +/*\n> + * IMPORTANT: Due to the way these color codes are emulated on Windows,\n> + * write them only using printf(), fprintf(), and fputs(). In particular,\n> + * do not use puts() or write().\n\nNor putchar nor putc... but they're part of the puts family, of course.\nMore worthwhile then listing those negatives could be a hint on another\npositive: color_fprintf and friends which are declared at the end of\ncolor.h.\n\n> + */\n> #define GIT_COLOR_NORMAL\t\"\"\n> #define GIT_COLOR_RESET\t\t\"\\033[m\"\n> #define GIT_COLOR_BOLD\t\t\"\\033[1m\"\n"}]}