David Aguilar [off-list ref] writes:
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
The bash completion (in contrib/) does read from the command list
IIRC. I do not think it relies on the messages, though.
From: "Junio C Hamano" <redacted>
Sent: Sunday, February 24, 2013 8:59 AM
David Aguilar [off-list ref] writes:
quoted
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
I'd read the messages in the tone 'commands of the Git system', but I
can see that both views are equally plausible. Though the final _("git:
'%s' is not a Git command. See 'git --help'.") can't be referring to a
'git-<cmd>', obviously ;-)
quoted
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
The bash completion (in contrib/) does read from the command list
IIRC. I do not think it relies on the messages, though.
I was aware of that bash completion used 'git help -a' so I avoided
changing the response to that option. Initially I'd thought of making
'-a' provide both commands and guides but knew I'd need to ensure the
completion would still be sensible. I'd taken Juio's earlier advice to
keep '-a' unchanged and simply add the -g|--guides option as a
supplemental 'git help' response..
Philip
On Sun, Feb 24, 2013 at 12:59 AM, Junio C Hamano [off-list ref] wrote:
David Aguilar [off-list ref] writes:
quoted
This is referring to "git the command", not "git the system",
so it should not be changed according to the rule that was
applied when many "git" strings were changed to "Git".
That sounds like a sensible objection.
quoted
There are scripts, etc. in the wild that parse this output.
which is another reason we would not want to change this.
Are there? For what purpose?
Especially when these are all _("l10n ready"), I find that somewhat
unlikely.
A script might conditionally use new git behavior and parse the
output of "git version" to determine whether or not it can use it.
oh-my-zsh does this, for example [*].
Changing the git to Git is probably fine for some scripts that
do something interesting based on the git version since they
might be doing something simple like splitting the string on
whitespace and taking the last element as the version number.
These won't be broken by this change, but this approach is
already broken for a different reason. Apple's build of git
prints "git version 1.7.12.4 (Apple Git-37)" so they would
need to account for the last parens section optionally
being there. Changing "git" to "Git" only breaks anyone that
has assumed that they could get the version by doing
s/git version// on the string.
I think being able to find the version at runtime is something
that is typically used by packagers and folks that want to be
portable across git versions. For these, it would be helpful
to have a consistent and stable output that can be easily parsed.
By deciding to not mark these l10n ready and keeping the output
consistent we could help that use case.
[*] I'm not saying this is a good idea or something that scripts
should do, I'm just pointing out that it is done in practice,
so it is worth considering their use cases.
--
David