{"thread":{"id":"39197","subject":"Patch that modifies git usage message","startedAt":"2015-05-01T11:01:16Z","lastAt":"2015-05-01T18:01:31Z","messageCount":10,"participants":["Alangi Derick","Stefan Beller","Junio C Hamano","Eric Sunshine"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"260310","messageId":"CAKB+oNtYbJXNb2wGzJCdQ5Ru5fq3HzcapSqiTVC_34=xDnTb7Q@mail.gmail.com","threadId":"39197","inReplyTo":null,"subject":"Patch that modifies git usage message","fromName":"Alangi Derick","fromEmail":"alangiderick@gmail.com","sentAt":"2015-05-01T11:01:16Z","receivedAt":"2015-05-01T11:01:16Z","isPatch":false,"sender":{"key":"alangiderick@gmail.com","avatar":"https://gravatar.com/avatar/f5878e69e83b4cf7ed499336c4a114dc2cb253253bc57c9b8ffcf0e129320795?d=mp&s=160"},"body":"This patch just modifies the \"usage\" word to \"Usage\" which enhances\nreadability. Below is the patch\n\nRegards\nAlangi Derick Ndimnain\n\n\ndiff --git a/git.c b/git.c\nindex 42a4ee5..481aa74 100644\n--- a/git.c\n+++ b/git.c\n@@ -667,7 +667,7 @@ int main(int argc, char **av)\n \t} else {\n \t\t/* The user didn't specify a command; give them help */\n \t\tcommit_pager_choice();\n-\t\tprintf(\"usage: %s\\n\\n\", git_usage_string);\n+\t\tprintf(\"Usage: %s\\n\\n\", git_usage_string);\n \t\tlist_common_cmds_help();\n \t\tprintf(\"\\n%s\\n\", _(git_more_info_string));\n \t\texit(1);\n"},{"id":"260348","messageId":"CAGZ79kY1ZoYrVwVVqfyB+uMGsJo59qDxbDLgyo5qygSm=CUVhA@mail.gmail.com","threadId":"39197","inReplyTo":"CAKB+oNtYbJXNb2wGzJCdQ5Ru5fq3HzcapSqiTVC_34=xDnTb7Q@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-05-01T15:51:07Z","receivedAt":"2015-05-01T15:51:07Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, May 1, 2015 at 4:01 AM, Alangi Derick <alangiderick@gmail.com> wrote:\n> This patch just modifies the \"usage\" word to \"Usage\" which enhances\n> readability. Below is the patch\n>\n> Regards\n> Alangi Derick Ndimnain\n\nIt's easier to have the patch in the email itself, this looks it's\nsome form of attachment.\n\nCheckout Documentation/SubmittingPatches (protip: get \"git send-email\"\nworking, it will\nsend in the preferred way by default for nearly any open source\nproject using email based\nworkflows.)\n\nThere are also some resources on the web, how to send patches,\nalthough it should be\nall covered in our Documentation,\nhttp://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html\n\nFor the patch itself:\n\n$ grep -r usage *.c builtin/*.c |wc -l\n551\n$ grep -r Usage *.c builtin/*.c |wc -l\n3\n\nThe community agreed (maybe subconciously) to prefer lower case\nfor the 'usage' string, so I don't think this is an improvement.\n"},{"id":"260350","messageId":"CAKB+oNtsy4E5Y6d3VCvdrjRTsdqARu8nJPYjH5J-qUenirR8mg@mail.gmail.com","threadId":"39197","inReplyTo":"CAGZ79kY1ZoYrVwVVqfyB+uMGsJo59qDxbDLgyo5qygSm=CUVhA@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Alangi Derick","fromEmail":"alangiderick@gmail.com","sentAt":"2015-05-01T15:54:38Z","receivedAt":"2015-05-01T15:54:38Z","isPatch":false,"sender":{"key":"alangiderick@gmail.com","avatar":"https://gravatar.com/avatar/f5878e69e83b4cf7ed499336c4a114dc2cb253253bc57c9b8ffcf0e129320795?d=mp&s=160"},"body":"I am saying so because there are some strings with upper case letters\nand others with lower case letters. So there is no consistency. That\nis why i wanted to keep the consistency by correcting the letters\nwhich are to be corrected and allow the once which are to be allowed.\nRegards\nAlangi Derick Ndimnain\n\n\nOn Fri, May 1, 2015 at 4:51 PM, Stefan Beller <sbeller@google.com> wrote:\n> On Fri, May 1, 2015 at 4:01 AM, Alangi Derick <alangiderick@gmail.com> wrote:\n>> This patch just modifies the \"usage\" word to \"Usage\" which enhances\n>> readability. Below is the patch\n>>\n>> Regards\n>> Alangi Derick Ndimnain\n>\n> It's easier to have the patch in the email itself, this looks it's\n> some form of attachment.\n>\n> Checkout Documentation/SubmittingPatches (protip: get \"git send-email\"\n> working, it will\n> send in the preferred way by default for nearly any open source\n> project using email based\n> workflows.)\n>\n> There are also some resources on the web, how to send patches,\n> although it should be\n> all covered in our Documentation,\n> http://alblue.bandlem.com/2011/12/git-tip-of-week-patches-by-email.html\n>\n> For the patch itself:\n>\n> $ grep -r usage *.c builtin/*.c |wc -l\n> 551\n> $ grep -r Usage *.c builtin/*.c |wc -l\n> 3\n>\n> The community agreed (maybe subconciously) to prefer lower case\n> for the 'usage' string, so I don't think this is an improvement.\n"},{"id":"260352","messageId":"xmqqfv7gxnup.fsf@gitster.dls.corp.google.com","threadId":"39197","inReplyTo":"CAGZ79kY1ZoYrVwVVqfyB+uMGsJo59qDxbDLgyo5qygSm=CUVhA@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2015-05-01T16:29:50Z","receivedAt":"2015-05-01T16:29:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stefan Beller <sbeller@google.com> writes:\n\n> For the patch itself:\n>\n> $ grep -r usage *.c builtin/*.c |wc -l\n> 551\n> $ grep -r Usage *.c builtin/*.c |wc -l\n> 3\n>\n> The community agreed (maybe subconciously) to prefer lower case\n> for the 'usage' string, so I don't think this is an improvement.\n\nI tend to agree with the conclusion, but you need to be a bit\ncareful here.  These catch all the variable names that contain\n\"[uU]sage\" as substring, but we do not spell in-code variables\nwith camelCase, so the former probably is over-counting.  Things\nlike \"static const char usage[] = ...\" are counted; so are calls\nto usage_with_options().\n\nIf you look for the beginning of a string constant, you would get\nthis:\n\n    $ git grep '\"usage' -- \\*.c builtin/\\*.c\n    12\n    $ git grep '\"Usage' -- \\*.c builtin/\\*.c\n    0\n\nThe former undercounts the messages because many usage messages are\nproduced by calling usage_with_options() these days.\n\nThe latter being zero made me scratch my head and do this:\n\n    $ git grep Usage -- \\*.c builtin/\\*.c\n    commit.c: * Usage example:\n    test-hashmap.c: * Usage: time echo \"perfhas...\n\nI cannot find the third one you found for \"Usage\" in your example,\nthough.\n"},{"id":"260354","messageId":"CAKB+oNtKi6e7H9U75WEJDKH2KK349JT+vGE8+acHvM6SasCWfQ@mail.gmail.com","threadId":"39197","inReplyTo":"xmqqfv7gxnup.fsf@gitster.dls.corp.google.com","subject":"Re: Patch that modifies git usage message","fromName":"Alangi Derick","fromEmail":"alangiderick@gmail.com","sentAt":"2015-05-01T16:38:58Z","receivedAt":"2015-05-01T16:38:58Z","isPatch":false,"sender":{"key":"alangiderick@gmail.com","avatar":"https://gravatar.com/avatar/f5878e69e83b4cf7ed499336c4a114dc2cb253253bc57c9b8ffcf0e129320795?d=mp&s=160"},"body":"Ok, thanks for the correction. What about the other strings used for\nerror display? For example\ndie(\"cannot handle %s as a builtin\", cmd);\nCan't i change the \"cannot\" to \"Cannot\"? Or is there a problem with\nthat one too?\nRegards\nAlangi Derick Ndimnain\n\n\nOn Fri, May 1, 2015 at 5:29 PM, Junio C Hamano <gitster@pobox.com> wrote:\n> Stefan Beller <sbeller@google.com> writes:\n>\n>> For the patch itself:\n>>\n>> $ grep -r usage *.c builtin/*.c |wc -l\n>> 551\n>> $ grep -r Usage *.c builtin/*.c |wc -l\n>> 3\n>>\n>> The community agreed (maybe subconciously) to prefer lower case\n>> for the 'usage' string, so I don't think this is an improvement.\n>\n> I tend to agree with the conclusion, but you need to be a bit\n> careful here.  These catch all the variable names that contain\n> \"[uU]sage\" as substring, but we do not spell in-code variables\n> with camelCase, so the former probably is over-counting.  Things\n> like \"static const char usage[] = ...\" are counted; so are calls\n> to usage_with_options().\n>\n> If you look for the beginning of a string constant, you would get\n> this:\n>\n>     $ git grep '\"usage' -- \\*.c builtin/\\*.c\n>     12\n>     $ git grep '\"Usage' -- \\*.c builtin/\\*.c\n>     0\n>\n> The former undercounts the messages because many usage messages are\n> produced by calling usage_with_options() these days.\n>\n> The latter being zero made me scratch my head and do this:\n>\n>     $ git grep Usage -- \\*.c builtin/\\*.c\n>     commit.c: * Usage example:\n>     test-hashmap.c: * Usage: time echo \"perfhas...\n>\n> I cannot find the third one you found for \"Usage\" in your example,\n> though.\n"},{"id":"260355","messageId":"CAGZ79kY4zJ2EhrtinaWChX=hLKywFu38wpF-mo=xrturxVh0=g@mail.gmail.com","threadId":"39197","inReplyTo":"xmqqfv7gxnup.fsf@gitster.dls.corp.google.com","subject":"Re: Patch that modifies git usage message","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-05-01T16:55:21Z","receivedAt":"2015-05-01T16:55:21Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, May 1, 2015 at 9:29 AM, Junio C Hamano <gitster@pobox.com> wrote:\n> Stefan Beller <sbeller@google.com> writes:\n>\n>> For the patch itself:\n>>\n>> $ grep -r usage *.c builtin/*.c |wc -l\n>> 551\n>> $ grep -r Usage *.c builtin/*.c |wc -l\n>> 3\n>>\n>> The community agreed (maybe subconciously) to prefer lower case\n>> for the 'usage' string, so I don't think this is an improvement.\n>\n> I tend to agree with the conclusion, but you need to be a bit\n> careful here.  These catch all the variable names that contain\n> \"[uU]sage\" as substring, but we do not spell in-code variables\n> with camelCase, so the former probably is over-counting.  Things\n> like \"static const char usage[] = ...\" are counted; so are calls\n> to usage_with_options().\n\nI knew my search was off as I did not think it through, but I\njust wanted to have at least some data to not be hand waving only\nhere.\n\nMaybe we can also rely on the colon in this case:\n$ grep -r \"usage:\" *.{c,sh,perl}\nfinds 22 results, 21 thereof look like human readable usage instructions\n$ grep -r \"Usage:\" *.{c,sh,perl}\nfinds 2 results which look like human readable text\n\n>\n> If you look for the beginning of a string constant, you would get\n> this:\n>\n>     $ git grep '\"usage' -- \\*.c builtin/\\*.c\n>     12\n>     $ git grep '\"Usage' -- \\*.c builtin/\\*.c\n>     0\n>\n> The former undercounts the messages because many usage messages are\n> produced by calling usage_with_options() these days.\n>\n> The latter being zero made me scratch my head and do this:\n>\n>     $ git grep Usage -- \\*.c builtin/\\*.c\n>     commit.c: * Usage example:\n>     test-hashmap.c: * Usage: time echo \"perfhas...\n>\n> I cannot find the third one you found for \"Usage\" in your example,\n> though.\n\ntest-submodule-config.c: fprintf(stderr, \"Usage: %s [<commit>\n<submodulepath>] ...\\n\", argv[0]);\n(I just realize HEAD wa pointing somewhere in pu)\n"},{"id":"260356","messageId":"CAGZ79kZcBSLhR1HBsHy2xgsGxp-Fwed1h-LBhSrXqKHp9XWQFw@mail.gmail.com","threadId":"39197","inReplyTo":"CAKB+oNtKi6e7H9U75WEJDKH2KK349JT+vGE8+acHvM6SasCWfQ@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Stefan Beller","fromEmail":"sbeller@google.com","sentAt":"2015-05-01T16:55:48Z","receivedAt":"2015-05-01T16:55:48Z","isPatch":false,"sender":{"key":"stefanbeller@gmail.com","avatar":"https://avatars.githubusercontent.com/u/455868?v=4"},"body":"On Fri, May 1, 2015 at 9:38 AM, Alangi Derick <alangiderick@gmail.com> wrote:\n> Can't i change the \"cannot\" to \"Cannot\"? Or is there a problem with\n> that one too?\n\nWell maybe you can make a strong argument for changing it like you'd\nfind it inconsistencies in different spots.\n\nIf you're in the game just to change a thing or get a patch into Git,\nyou may want to look at\nhttp://git-blame.blogspot.com/p/leftover-bits.html\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n(As you seem to focus on the textual UI, maybe\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas#improve_.22git_help.22\nmight be a good idea to start with?)\n"},{"id":"260362","messageId":"CAPig+cROY5ZaXtAWpaMpe8JsuG1eSp2jhAsSh1dAsCSACgoFxw@mail.gmail.com","threadId":"39197","inReplyTo":"CAKB+oNtKi6e7H9U75WEJDKH2KK349JT+vGE8+acHvM6SasCWfQ@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-01T17:40:21Z","receivedAt":"2015-05-01T17:40:21Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"(Etiquette on this list is to reply inline rather than top-posting[1].)\n\nOn Fri, May 1, 2015 at 12:38 PM, Alangi Derick <alangiderick@gmail.com> wrote:\n> What about the other strings used for\n> error display? For example\n> die(\"cannot handle %s as a builtin\", cmd);\n> Can't i change the \"cannot\" to \"Cannot\"? Or is there a problem with\n> that one too?\n\nDespite inconsistencies in existing code, lowercase in new error\nmessages is intentional. Documentation/CodingGuidelines has this to\nsay[2]:\n\n    Error Messages\n\n    - Do not capitalize (\"unable to open %s\", not \"Unable to\n      open %s\")\n\nTherefore, a goal more aligned with this recommendation would be to\nsubmit a patch which changes capitalized error messages to lowercase,\nhowever, heed this warning[3] from CodingGuidelines:\n\n   - Fixing style violations while working on a real change as a\n     preparatory clean-up step is good, but otherwise avoid useless\n     code churn for the sake of conforming to the style.\n\n     \"Once it _is_ in the tree, it's not really worth the patch noise\n     to go and fix it up.\"\n     Cf. http://article.gmane.org/gmane.linux.kernel/943020\n\nSometimes there are exceptions. One may be able to argue that making\nuser-facing messages more consistent is worthwhile (for instance [4]).\n\nFinally, changing \"usage:\" to \"Usage:\" would undo recent work to\nimprove consistency of usage messages[4].\n\n[1]: https://lkml.org/lkml/2005/1/11/111\n[2]: https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L416\n[3]: https://github.com/git/git/blob/master/Documentation/CodingGuidelines#L21\n[4]: http://thread.gmane.org/gmane.comp.version-control.git/216961\n"},{"id":"260363","messageId":"CAKB+oNvSR4ifdCZAxTyhwoh-yeVxikB0+Z9+19MGyVv4yLB=Xw@mail.gmail.com","threadId":"39197","inReplyTo":"CAPig+cROY5ZaXtAWpaMpe8JsuG1eSp2jhAsSh1dAsCSACgoFxw@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Alangi Derick","fromEmail":"alangiderick@gmail.com","sentAt":"2015-05-01T17:49:17Z","receivedAt":"2015-05-01T17:49:17Z","isPatch":false,"sender":{"key":"alangiderick@gmail.com","avatar":"https://gravatar.com/avatar/f5878e69e83b4cf7ed499336c4a114dc2cb253253bc57c9b8ffcf0e129320795?d=mp&s=160"},"body":"So in essence what you are saying is that i should instead change\nerror messages to lower case. And also i have seen an idea i want to\nwork on from\nhttps://git.wiki.kernel.org/index.php/SmallProjectsIdeas\nI want to work on this and will submit a patch as soon as i am done.\n"},{"id":"260366","messageId":"CAPig+cS1t9jz8Dr+p89Ly5OG1dhiFqvyBxjgbvMhtSpk1VFqmA@mail.gmail.com","threadId":"39197","inReplyTo":"CAKB+oNvSR4ifdCZAxTyhwoh-yeVxikB0+Z9+19MGyVv4yLB=Xw@mail.gmail.com","subject":"Re: Patch that modifies git usage message","fromName":"Eric Sunshine","fromEmail":"sunshine@sunshineco.com","sentAt":"2015-05-01T18:01:31Z","receivedAt":"2015-05-01T18:01:31Z","isPatch":false,"sender":{"key":"sunshine@sunshineco.com","avatar":"https://avatars.githubusercontent.com/u/163641?v=4"},"body":"On Fri, May 1, 2015 at 1:49 PM, Alangi Derick <alangiderick@gmail.com> wrote:\n> So in essence what you are saying is that i should instead change\n> error messages to lower case.\n\nNo, I'm not saying that you _should_ do anything. I am saying merely\nthat if you were to submit such a patch for the sake of improving\nconsistency, you might have an easier time convincing people that your\npatch is worthwhile if you follow the current trend (which is to make\nerror messages lowercase).\n\nHowever, I'm also saying that such a patch may encounter resistance if\nit is perceived as mere \"noise\", as explained by the CodingGuidelines\nblurb which I cited.\n\n> And also i have seen an idea i want to work on from\n> https://git.wiki.kernel.org/index.php/SmallProjectsIdeas\n> I want to work on this and will submit a patch as soon as i am done.\n"}]}