{"thread":{"id":"33027","subject":"Re: [PATCH 01/13] Use 'Git' in help messages","startedAt":"2013-02-26T22:38:00Z","lastAt":"2013-02-26T22:38:00Z","messageCount":1,"participants":["Philip Oakley"],"isPatch":true,"patchVersion":1,"patchTotal":13},"messages":[{"id":"210377","messageId":"96C279DB1BA3478ABA712FF00EAB6C13@PhilipOakley","threadId":"33027","inReplyTo":null,"subject":"Re: [PATCH 01/13] Use 'Git' in help messages","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2013-02-26T22:38:00Z","isPatch":true,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Philip Oakley\" <philipoakley@iee.org>\nSent: Sunday, February 24, 2013 9:50 PM\n> From: \"Junio C Hamano\" <gitster@pobox.com>\n> Sent: Sunday, February 24, 2013 8:59 AM\n>> David Aguilar <davvid@gmail.com> writes:\n>>\n>>> This is referring to \"git the command\", not \"git the system\",\n>>> so it should not be changed according to the rule that was\n>>> applied when many \"git\" strings were changed to \"Git\".\n>>\n>> That sounds like a sensible objection.\n>>\n>\n> I'd read the messages in the tone 'commands of the Git system', but I \n> can see that both views are equally plausible. Though the final \n> _(\"git: '%s' is not a Git command. See 'git --help'.\") can't be \n> referring to a 'git-<cmd>', obviously ;-)\n>\n>>> There are scripts, etc. in the wild that parse this output.\n>>> which is another reason we would not want to change this.\n>>\n>> Are there?  For what purpose?\n>>\n\nJust found that Git Gui checks for the version number (line 936)\n\n    if {![regsub {^git version } $_git_version {} _git_version]} {\n\nand then parses for the dot separated digits etc.\n\nSo looks like the version string change would be a problematic \nregression.\n\nGiven the change elsewhere of 'Usage:' to 'usage:' it looks like I \nshould drop this patch.\n\n>> Especially when these are all _(\"l10n ready\"), I find that somewhat\n>> unlikely.\n>>\n>> The bash completion (in contrib/) does read from the command list\n>> IIRC.  I do not think it relies on the messages, though.\n>\n> I was aware of that bash completion used 'git help -a' so I avoided \n> changing the response to that option. Initially I'd thought of making \n> '-a' provide both commands and guides but knew I'd need to ensure the \n> completion would still be sensible. I'd taken Juio's earlier advice to \n> keep '-a' unchanged and simply add the -g|--guides option as a \n> supplemental 'git help' response..\n>\n> Philip \n"}]}