{"thread":{"id":"29995","subject":"[PATCH 0/2] Unify the style of user messages","startedAt":"2012-03-19T17:51:41Z","lastAt":"2012-03-20T12:33:09Z","messageCount":10,"participants":["Vincent van Ravesteijn","Junio C Hamano","Jeff King","Jakub Narebski"],"isPatch":true,"patchVersion":1,"patchTotal":2},"messages":[{"id":"187264","messageId":"1332179503-2992-1-git-send-email-vfr@lyx.org","threadId":"29995","inReplyTo":null,"subject":"[PATCH 0/2] Unify the style of user messages","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-19T17:51:41Z","receivedAt":"2012-03-19T17:51:41Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"\n\n\nWhile working on the translations, I came accross these strings. There doesn't seem to be a rule on how these messages should be formatted (or there is, then I didn't look well enough).\n\nTo me it feels better to standardize the style, so I looked in the sourcecode for which style is used most and composed some guidelines to unify the messages:\n    - messages start with a capital,\n    - short messages do not end with a full stop,\n    - paths, filenames, and commands are quoted by single quotes (if not separated by the normal text by a ':'),\n    - 'could not' is used rather than 'cannot'. \n\nThere could of course be much more changes, but I don't know whether these changes are appreciated. Also, the guidelines might be disputable. Maybe it is not the best timing because we are in rc phase and the people start to translate. On the other hand, we might better change it before all translations are finished.\n\nThe second patch makes a few string translatable. \n\nVincent\n"},{"id":"187265","messageId":"1332179503-2992-2-git-send-email-vfr@lyx.org","threadId":"29995","inReplyTo":"1332179503-2992-1-git-send-email-vfr@lyx.org","subject":"[PATCH 1/2] Unification of user message strings","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-19T17:51:42Z","receivedAt":"2012-03-19T17:51:42Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"From: Vincent van Ravesteijn <vfr@lyx.org>\n\nRewrite user messages to stick to a uniform style for all messages. From the surrounding code, the following guidelines were deduced:\n- messages start with a capital,\n- short messages do not end with a full stop,\n- paths, filenames, and commands are quoted by single quotes (if not separated by the normal text by a ':'),\n- 'could not' is used rather than 'cannot'.\n\nSigned-off-by: Vincent van Ravesteijn <vfr@lyx.org>\n---\n gpg-interface.c |    6 +++---\n grep.c          |    2 +-\n help.c          |    2 +-\n sequencer.c     |   24 ++++++++++++------------\n 4 files changed, 17 insertions(+), 17 deletions(-)\n\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 09ab64a..5e14a21 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -56,7 +56,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig\n \targs[3] = NULL;\n \n \tif (start_command(&gpg))\n-\t\treturn error(_(\"could not run gpg.\"));\n+\t\treturn error(_(\"Could not run 'gpg'\"));\n \n \t/*\n \t * When the username signingkey is bad, program could be terminated\n@@ -68,7 +68,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig\n \t\tclose(gpg.in);\n \t\tclose(gpg.out);\n \t\tfinish_command(&gpg);\n-\t\treturn error(_(\"gpg did not accept the data\"));\n+\t\treturn error(_(\"'gpg' did not accept the data\"));\n \t}\n \tclose(gpg.in);\n \n@@ -79,7 +79,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig\n \tsigchain_pop(SIGPIPE);\n \n \tif (finish_command(&gpg) || !len || len < 0)\n-\t\treturn error(_(\"gpg failed to sign the data\"));\n+\t\treturn error(_(\"'gpg' failed to sign the data\"));\n \n \t/* Strip CR from the line endings, in case we are on Windows. */\n \tfor (i = j = bottom; i < signature->len; i++)\ndiff --git a/grep.c b/grep.c\nindex 190139c..6e0fef5 100644\n--- a/grep.c\n+++ b/grep.c\n@@ -1277,7 +1277,7 @@ static int grep_source_load_sha1(struct grep_source *gs)\n \tgrep_read_unlock();\n \n \tif (!gs->buf)\n-\t\treturn error(_(\"'%s': unable to read %s\"),\n+\t\treturn error(_(\"%s: unable to read '%s'\"),\n \t\t\t     gs->name,\n \t\t\t     sha1_to_hex(gs->identifier));\n \treturn 0;\ndiff --git a/help.c b/help.c\nindex 14eefc9..5ab076b 100644\n--- a/help.c\n+++ b/help.c\n@@ -285,7 +285,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)\n \n static const char bad_interpreter_advice[] =\n \tN_(\"'%s' appears to be a git command, but we were not\\n\"\n-\t\"able to execute it. Maybe git-%s is broken?\");\n+\t\"able to execute it. Maybe 'git-%s' is broken?\");\n \n const char *help_unknown_cmd(const char *cmd)\n {\ndiff --git a/sequencer.c b/sequencer.c\nindex a37846a..1554173 100644\n--- a/sequencer.c\n+++ b/sequencer.c\n@@ -156,10 +156,10 @@ static void write_message(struct strbuf *msgbuf, const char *filename)\n \tint msg_fd = hold_lock_file_for_update(&msg_file, filename,\n \t\t\t\t\t       LOCK_DIE_ON_ERROR);\n \tif (write_in_full(msg_fd, msgbuf->buf, msgbuf->len) < 0)\n-\t\tdie_errno(_(\"Could not write to %s\"), filename);\n+\t\tdie_errno(_(\"Could not write to '%s'\"), filename);\n \tstrbuf_release(msgbuf);\n \tif (commit_lock_file(&msg_file) < 0)\n-\t\tdie(_(\"Error wrapping up %s\"), filename);\n+\t\tdie(_(\"Error wrapping up '%s'\"), filename);\n }\n \n static struct tree *empty_tree(void)\n@@ -588,11 +588,11 @@ static void read_populate_todo(struct commit_list **todo_list,\n \n \tfd = open(todo_file, O_RDONLY);\n \tif (fd < 0)\n-\t\tdie_errno(_(\"Could not open %s\"), todo_file);\n+\t\tdie_errno(_(\"Could not open '%s'\"), todo_file);\n \tif (strbuf_read(&buf, fd, 0) < 0) {\n \t\tclose(fd);\n \t\tstrbuf_release(&buf);\n-\t\tdie(_(\"Could not read %s.\"), todo_file);\n+\t\tdie(_(\"Could not read '%s'\"), todo_file);\n \t}\n \tclose(fd);\n \n@@ -668,7 +668,7 @@ static int create_seq_dir(void)\n \t\treturn -1;\n \t}\n \telse if (mkdir(seq_dir, 0777) < 0)\n-\t\tdie_errno(_(\"Could not create sequencer directory %s\"), seq_dir);\n+\t\tdie_errno(_(\"Could not create sequencer directory '%s'\"), seq_dir);\n \treturn 0;\n }\n \n@@ -682,9 +682,9 @@ static void save_head(const char *head)\n \tfd = hold_lock_file_for_update(&head_lock, head_file, LOCK_DIE_ON_ERROR);\n \tstrbuf_addf(&buf, \"%s\\n\", head);\n \tif (write_in_full(fd, buf.buf, buf.len) < 0)\n-\t\tdie_errno(_(\"Could not write to %s\"), head_file);\n+\t\tdie_errno(_(\"Could not write to '%s'\"), head_file);\n \tif (commit_lock_file(&head_lock) < 0)\n-\t\tdie(_(\"Error wrapping up %s.\"), head_file);\n+\t\tdie(_(\"Error wrapping up '%s'\"), head_file);\n }\n \n static int reset_for_rollback(const unsigned char *sha1)\n@@ -729,10 +729,10 @@ static int sequencer_rollback(struct replay_opts *opts)\n \t\treturn rollback_single_pick();\n \t}\n \tif (!f)\n-\t\treturn error(_(\"cannot open %s: %s\"), filename,\n+\t\treturn error(_(\"Could not open '%s': %s\"), filename,\n \t\t\t\t\t\tstrerror(errno));\n \tif (strbuf_getline(&buf, f, '\\n')) {\n-\t\terror(_(\"cannot read %s: %s\"), filename, ferror(f) ?\n+\t\terror(_(\"Could not read '%s': %s\"), filename, ferror(f) ?\n \t\t\tstrerror(errno) : _(\"unexpected end of file\"));\n \t\tfclose(f);\n \t\tgoto fail;\n@@ -762,14 +762,14 @@ static void save_todo(struct commit_list *todo_list, struct replay_opts *opts)\n \n \tfd = hold_lock_file_for_update(&todo_lock, todo_file, LOCK_DIE_ON_ERROR);\n \tif (format_todo(&buf, todo_list, opts) < 0)\n-\t\tdie(_(\"Could not format %s.\"), todo_file);\n+\t\tdie(_(\"Could not format '%s'\"), todo_file);\n \tif (write_in_full(fd, buf.buf, buf.len) < 0) {\n \t\tstrbuf_release(&buf);\n-\t\tdie_errno(_(\"Could not write to %s\"), todo_file);\n+\t\tdie_errno(_(\"Could not write to '%s'\"), todo_file);\n \t}\n \tif (commit_lock_file(&todo_lock) < 0) {\n \t\tstrbuf_release(&buf);\n-\t\tdie(_(\"Error wrapping up %s.\"), todo_file);\n+\t\tdie(_(\"Error wrapping up '%s'\"), todo_file);\n \t}\n \tstrbuf_release(&buf);\n }\n-- \n1.7.5.4\n"},{"id":"187266","messageId":"1332179503-2992-3-git-send-email-vfr@lyx.org","threadId":"29995","inReplyTo":"1332179503-2992-1-git-send-email-vfr@lyx.org","subject":"[PATCH 2/2] Make some strings translatable","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-19T17:51:43Z","receivedAt":"2012-03-19T17:51:43Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"From: Vincent van Ravesteijn <vfr@lyx.org>\n\nThese strings seem not to be part of the plumbing interface and can therefore be translated. Also the style is adjusted to the guidelines mentioned in the previous commit.\n\nSigned-off-by: Vincent van Ravesteijn <vfr@lyx.org>\n---\n gpg-interface.c |    6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/gpg-interface.c b/gpg-interface.c\nindex 5e14a21..66a7c12 100644\n--- a/gpg-interface.c\n+++ b/gpg-interface.c\n@@ -109,10 +109,10 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n \targs_gpg[0] = gpg_program;\n \tfd = git_mkstemp(path, PATH_MAX, \".git_vtag_tmpXXXXXX\");\n \tif (fd < 0)\n-\t\treturn error(\"could not create temporary file '%s': %s\",\n+\t\treturn error(_(\"Could not create temporary file '%s': %s\"),\n \t\t\t     path, strerror(errno));\n \tif (write_in_full(fd, signature, signature_size) < 0)\n-\t\treturn error(\"failed writing detached signature to '%s': %s\",\n+\t\treturn error(_(\"Failed writing detached signature to '%s': %s\"),\n \t\t\t     path, strerror(errno));\n \tclose(fd);\n \n@@ -124,7 +124,7 @@ int verify_signed_buffer(const char *payload, size_t payload_size,\n \targs_gpg[2] = path;\n \tif (start_command(&gpg)) {\n \t\tunlink(path);\n-\t\treturn error(\"could not run gpg.\");\n+\t\treturn error(_(\"Could not run 'gpg'\"));\n \t}\n \n \twrite_in_full(gpg.in, payload, payload_size);\n-- \n1.7.5.4\n"},{"id":"187271","messageId":"7v1uoobcsv.fsf@alter.siamese.dyndns.org","threadId":"29995","inReplyTo":"1332179503-2992-2-git-send-email-vfr@lyx.org","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T19:39:28Z","receivedAt":"2012-03-19T19:39:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Vincent van Ravesteijn <vfr@lyx.org> writes:\n\n> From: Vincent van Ravesteijn <vfr@lyx.org>\n>\n> Rewrite user messages to stick to a uniform style for all messages. From the surrounding code, the following guidelines were deduced:\n> - messages start with a capital,\n> - short messages do not end with a full stop,\n> - paths, filenames, and commands are quoted by single quotes (if not separated by the normal text by a ':'),\n> - 'could not' is used rather than 'cannot'.\n>\n> Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org>\n> ---\n>  gpg-interface.c |    6 +++---\n>  grep.c          |    2 +-\n>  help.c          |    2 +-\n>  sequencer.c     |   24 ++++++++++++------------\n>  4 files changed, 17 insertions(+), 17 deletions(-)\n>\n> diff --git a/gpg-interface.c b/gpg-interface.c\n> index 09ab64a..5e14a21 100644\n> --- a/gpg-interface.c\n> +++ b/gpg-interface.c\n> @@ -56,7 +56,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig\n>  \targs[3] = NULL;\n>  \n>  \tif (start_command(&gpg))\n> -\t\treturn error(_(\"could not run gpg.\"));\n> +\t\treturn error(_(\"Could not run 'gpg'\"));\n\nOk with s/c/C/, but I am not sure about the 'gpg' bit.  The name of the\nprogram and path to it can be configured so the user may be expecting to\nrun a program called gnupg, and unquoted gpg feels more like a generic\nterm to refer to the program.  It might be worth using all-CAPS, though.\n\nLikewise for the other hunks for this file.\n\n> -\t\treturn error(_(\"cannot open %s: %s\"), filename,\n> +\t\treturn error(_(\"Could not open '%s': %s\"), filename,\n\nHonestly speaking, I would personally prefer \"Cannot open\" over \"Could not\nopen\".  Yes, all the error messages report _after_ we attempted to do\nsomething and finding that we _couldn't_ do that thing, so \"Could not\" may\nbe technically more correct, but still...\n\nBut that is probably just me.\n\nOther than that, the patch looks good; let's hear from others, too.\n"},{"id":"187275","messageId":"4F679419.8020204@lyx.org","threadId":"29995","inReplyTo":"7v1uoobcsv.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-19T20:16:25Z","receivedAt":"2012-03-19T20:16:25Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"\n>> From: Vincent van Ravesteijn<vfr@lyx.org>\n>>\n>> Rewrite user messages to stick to a uniform style for all messages. From the surrounding code, the following guidelines were deduced:\n>> - messages start with a capital,\n>> - short messages do not end with a full stop,\n>> - paths, filenames, and commands are quoted by single quotes (if not separated by the normal text by a ':'),\n>> - 'could not' is used rather than 'cannot'.\n>>\n>>\n>> @@ -56,7 +56,7 @@ int sign_buffer(struct strbuf *buffer, struct strbuf *signature, const char *sig\n>>   \targs[3] = NULL;\n>>\n>>   \tif (start_command(&gpg))\n>> -\t\treturn error(_(\"could not run gpg.\"));\n>> +\t\treturn error(_(\"Could not run 'gpg'\"));\n> Ok with s/c/C/, but I am not sure about the 'gpg' bit.  The name of the\n> program and path to it can be configured so the user may be expecting to\n> run a program called gnupg, and unquoted gpg feels more like a generic\n> term to refer to the program.  It might be worth using all-CAPS, though.\n\nYes, all-CAPS seems the better alternative.\n\n>> -\t\treturn error(_(\"cannot open %s: %s\"), filename,\n>> +\t\treturn error(_(\"Could not open '%s': %s\"), filename,\n> Honestly speaking, I would personally prefer \"Cannot open\" over \"Could not\n> open\".  Yes, all the error messages report _after_ we attempted to do\n> something and finding that we _couldn't_ do that thing, so \"Could not\" may\n> be technically more correct, but still...\n>\n> But that is probably just me.\n>\n\nNo it's not you, grep tells me \"Cannot\" is indeed the most occuring, \nexcept in sequencer.c (which I stumbled on first).\n\n\n> Other than that, the patch looks good; let's hear from others, too.\n\nOk, let's hear other comments, and then I will send a reroll to fix up \nthe things above.\n\nVincent\n"},{"id":"187277","messageId":"20120319205300.GA3039@sigill.intra.peff.net","threadId":"29995","inReplyTo":"1332179503-2992-2-git-send-email-vfr@lyx.org","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2012-03-19T20:53:00Z","receivedAt":"2012-03-19T20:53:00Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Mar 19, 2012 at 06:51:42PM +0100, Vincent van Ravesteijn wrote:\n\n> Rewrite user messages to stick to a uniform style for all messages.\n> From the surrounding code, the following guidelines were deduced:\n> - messages start with a capital,\n\nI was surprised by this one, as I think we generally use lower-case\nmessages. Grepping shows that lower-case has a slight edge, though it is\nfar from decided:\n\n  $ git grep -E '(error|die)\\((_\\()?\"[A-Z]' | wc -l\n  810\n  $ git grep -E '(error|die)\\((_\\()?\"[a-z]' | wc -l\n  1267\n\n-Peff\n\nPS I was curious if it was simply that some people prefer one way and\n   not the other, but the results are quite mixed. Below is the result\n   of a small script I wrote that calculates \"upper-casedness\" per\n   author using the above regexes and git-blame.\n\n   The first number is the percentage of an author's messages starting\n   with upper-case characters, followed by the total number of messages\n   for that author, followed by the author's name. I limited the output\n   to the top 20 by total number, as there is a long tail of people\n   contributing just a few messages.\n\n      0.14 37 Martin Koegler\n      0.14 42 Johannes Sixt\n      0.14 81 Jonathan Nieder\n      0.16 31 Pierre Habouzit\n      0.18 92 Nicolas Pitre\n      0.20 66 Jeff King\n      0.20 87 Linus Torvalds\n      0.26 348 Junio C Hamano\n      0.35 20 Christian Couder\n      0.37 43 Nguyễn Thái Ngọc Duy\n      0.39 18 René Scharfe\n      0.41 32 Miklos Vajna\n      0.45 270 Ævar Arnfjörð Bjarmason\n      0.47 129 Shawn O. Pearce\n      0.50 36 David Barr\n      0.54 57 Johannes Schindelin\n      0.62 39 Ramkumar Ramachandra\n      0.67 21 Daniel Barkalow\n      0.76 59 Johan Herland\n\n   You can see that some people are usually lowercase and some are usually\n   uppercase, but there are many people near 50%, doing both equally.\n   There's also some inaccuracy in my simplistic sampling. For example,\n   of my 13 upper-case messages, 11 of them are \"BUG:\".\n"},{"id":"187283","messageId":"7vaa3c9ste.fsf@alter.siamese.dyndns.org","threadId":"29995","inReplyTo":"20120319205300.GA3039@sigill.intra.peff.net","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-03-19T21:36:29Z","receivedAt":"2012-03-19T21:36:29Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> On Mon, Mar 19, 2012 at 06:51:42PM +0100, Vincent van Ravesteijn wrote:\n>\n>> Rewrite user messages to stick to a uniform style for all messages.\n>> From the surrounding code, the following guidelines were deduced:\n>> - messages start with a capital,\n>\n> I was surprised by this one, as I think we generally use lower-case\n> messages. Grepping shows that lower-case has a slight edge, though it is\n> far from decided:\n> ...\n> PS I was curious if it was simply that some people prefer one way and\n>    not the other, but the results are quite mixed. Below is the result\n>    of a small script I wrote that calculates \"upper-casedness\" per\n>    author using the above regexes and git-blame.\n> ...\n>    You can see that some people are usually lowercase and some are usually\n>    uppercase, but there are many people near 50%, doing both equally.\n>    There's also some inaccuracy in my simplistic sampling. For example,\n>    of my 13 upper-case messages, 11 of them are \"BUG:\".\n\nI had a vague impression that plumbing messages tend to be lowercase.  If\nit is not be too much trouble, it might be interesting to redo the numbers\ndivided into the plumbing and Porcelain messages. Perhaps these \"50%\"\nfolks updated both plumbing and Porcelain. Another possibility is that\nthey tried to follow the local convention when they added a new one, or\nreworded an existing one.\n\nIf we would be rewording, we would only be doing the Porcelain messages,\nso I am OK with either way.\n"},{"id":"187308","messageId":"4F683622.6010409@lyx.org","threadId":"29995","inReplyTo":"7vaa3c9ste.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-20T07:47:46Z","receivedAt":"2012-03-20T07:47:46Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":"> I had a vague impression that plumbing messages tend to be lowercase.  If\n> it is not be too much trouble, it might be interesting to redo the numbers\n> divided into the plumbing and Porcelain messages. Perhaps these \"50%\"\n> folks updated both plumbing and Porcelain. Another possibility is that\n> they tried to follow the local convention when they added a new one, or\n> reworded an existing one.\n>\n> If we would be rewording, we would only be doing the Porcelain messages,\n> so I am OK with either way.\n\nIt seems that the terms \"Porcelain\" and \"plumbing\" seems to be mixed up \nsomewhere.\n\n From 'git help status': \"The porcelain format is similar to the short \nformat, but is guaranteed not to change in a backwards-incompatible way \nbetween git versions or based on user configuration. This makes it ideal \nfor parsing by scripts\".\n\n From 'http://progit.org/book/ch9-1.html': \"....it has a bunch of verbs \nthat do low-level work and were designed to be chained together UNIX \nstyle or called from scripts. These commands are generally referred to \nas “plumbing” commands, and the more user-friendly commands are called \n“porcelain” commands.\"\n\nIt feels like 'porcelain' means: \"be careful, things break easily\"; and \n'plumbing' means: \"use all the force you want to get it into (a \nuser-friendly) shape\".\n\nSecond, to me it is not totally clear which strings are plumbing and \nwhich ones are porcelain. Is there a general rule to tell ? The \ncommand-list file says what the general intention of a command is, but \noften it's both plumbing as porcelain.\n\nCan anyone help me out here ?\n\nVincent\n"},{"id":"187316","messageId":"m339934h39.fsf@localhost.localdomain","threadId":"29995","inReplyTo":"4F683622.6010409@lyx.org","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2012-03-20T12:01:05Z","receivedAt":"2012-03-20T12:01:05Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Vincent van Ravesteijn <vfr@lyx.org> writes:\n\n> > I had a vague impression that plumbing messages tend to be lowercase.  If\n> > it is not be too much trouble, it might be interesting to redo the numbers\n> > divided into the plumbing and Porcelain messages. Perhaps these \"50%\"\n> > folks updated both plumbing and Porcelain. Another possibility is that\n> > they tried to follow the local convention when they added a new one, or\n> > reworded an existing one.\n> >\n> > If we would be rewording, we would only be doing the Porcelain messages,\n> > so I am OK with either way.\n> \n> It seems that the terms \"Porcelain\" and \"plumbing\" seems to be mixed\n> up somewhere.\n> \n>  From 'git help status': \"The porcelain format is similar to the short\n> format, but is guaranteed not to change in a backwards-incompatible\n> way between git versions or based on user configuration. This makes it\n> ideal for parsing by scripts\".\n\nThe '--porcelain' option means \"intended *for* parsing by porcelain\",\nnot that it is 'porcelain' output.\n \n>  From 'http://progit.org/book/ch9-1.html': \"....it has a bunch of\n> verbs that do low-level work and were designed to be chained together\n> UNIX style or called from scripts. These commands are generally\n> referred to as 'plumbing' commands, and the more user-friendly\n> commands are called 'porcelain' commands.\"\n\nMnemonics: \"plumbing\" are hidden 'guts' of git (the engine / backend\npart).\n\n> It feels like 'porcelain' means: \"be careful, things break easily\";\n> and 'plumbing' means: \"use all the force you want to get it into (a\n> user-friendly) shape\".\n> \n> Second, to me it is not totally clear which strings are plumbing and\n> which ones are porcelain. Is there a general rule to tell ? The\n> command-list file says what the general intention of a command is, but\n> often it's both plumbing as porcelain.\n\n\"Porcelain\" commands are those that are facing user (as is \"porcelain\"\nin armature), so they might be changed to make it more user friendly.\n \n\"Plumbing\" command output is to be consumed by other commands and\nscripts, so it must be 'cast in stone' and cannot be changed.  It is\nmeant to be easily machine-parseable, and not to be user friendly.\n\n> Can anyone help me out here ?\n\nHTH\n-- \nJakub Narebski\n"},{"id":"187323","messageId":"4F687905.6070200@lyx.org","threadId":"29995","inReplyTo":"m339934h39.fsf@localhost.localdomain","subject":"Re: [PATCH 1/2] Unification of user message strings","fromName":"Vincent van Ravesteijn","fromEmail":"vfr@lyx.org","sentAt":"2012-03-20T12:33:09Z","receivedAt":"2012-03-20T12:33:09Z","isPatch":true,"sender":{"key":"vfr@lyx.org","avatar":"https://avatars.githubusercontent.com/u/687868?v=4"},"body":">>\n>> It seems that the terms \"Porcelain\" and \"plumbing\" seems to be mixed\n>> up somewhere.\n>>\n>>   From 'git help status': \"PORCELAIN FORMAT: The porcelain format is\n>> similar to the short format, but is guaranteed not to change in a\n>> backwards-incompatible way between git versions or based on user\n>> configuration. This makes it ideal for parsing by scripts\".\n> The '--porcelain' option means \"intended *for* parsing by porcelain\",\n> not that it is 'porcelain' output.\n\nI've a hard time to interpret the quote above in the way you explain. \nMaybe a little improvement to this description would be helpful.\n\n>\n> HTH\n\nThanks.\n\nVincent\n"}]}