From: David Aguilar <davvid@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: Philip Oakley <philipoakley@iee.org>, GitList <git@vger.kernel.org>
Subject: Re: [PATCH 01/13] Use 'Git' in help messages
Date: Sun, 24 Feb 2013 14:11:12 -0800 [thread overview]
Message-ID: <CAJDDKr4sCBJs_Dq8MdfCJAH4wW7k0TtimW6B01wS6k0zcJ9XHQ@mail.gmail.com> (raw)
In-Reply-To: <7vr4k65box.fsf@alter.siamese.dyndns.org>
On Sun, Feb 24, 2013 at 12:59 AM, Junio C Hamano <gitster@pobox.com> wrote:
> David Aguilar <davvid@gmail.com> 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.
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
next prev parent reply other threads:[~2013-02-24 22:11 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-23 23:05 [PATCH 00/13] Git help option to list user guides Philip Oakley
2013-02-23 23:05 ` [PATCH 01/13] Use 'Git' in help messages Philip Oakley
2013-02-23 23:41 ` David Aguilar
2013-02-23 23:54 ` Philip Oakley
2013-02-24 8:59 ` Junio C Hamano
2013-02-24 21:50 ` Philip Oakley
2013-02-24 22:11 ` David Aguilar [this message]
2013-02-23 23:05 ` [PATCH 02/13] Show 'git help <guide>' usage, with examples Philip Oakley
2013-02-24 14:39 ` W. Trevor King
2013-02-24 22:05 ` Philip Oakley
2013-02-23 23:05 ` [PATCH 03/13] Help.c use OPT_COUNTUP Philip Oakley
2013-02-23 23:05 ` [PATCH 04/13] Help.c add --guide option Philip Oakley
2013-02-23 23:05 ` [PATCH 05/13] Help.c: add list_common_guides_help() function Philip Oakley
2013-02-24 9:01 ` Junio C Hamano
2013-02-24 21:51 ` Philip Oakley
2013-02-25 5:24 ` Junio C Hamano
2013-02-25 23:43 ` Philip Oakley
2013-02-25 23:55 ` Junio C Hamano
2013-02-23 23:05 ` [PATCH 06/13] Add guide-list.txt and extraction shell Philip Oakley
2013-02-24 14:51 ` W. Trevor King
2013-02-24 22:12 ` Philip Oakley
2013-02-23 23:05 ` [PATCH 07/13] Extend name string for longer names Philip Oakley
2013-02-23 23:05 ` [PATCH 09/13] Rename everyday to giteveryday Philip Oakley
2013-02-24 14:55 ` W. Trevor King
2013-02-24 22:16 ` Philip Oakley
2013-02-23 23:05 ` [PATCH 10/13] Update Git(1) links to guides Philip Oakley
2013-02-23 23:05 ` [PATCH 11/13] Add missing guides to list and regenerate Philip Oakley
2013-02-23 23:06 ` [PATCH 12/13] Documentation/Makefile: update git guide links Philip Oakley
2013-02-24 14:58 ` W. Trevor King
2013-02-24 22:31 ` Philip Oakley
2013-02-25 5:29 ` Junio C Hamano
2013-02-25 23:43 ` Philip Oakley
2013-02-26 0:04 ` Junio C Hamano
2013-02-26 20:24 ` Philip Oakley
2013-02-23 23:06 ` [PATCH 13/13] Fixup! doc: giteveryday and user-manual man format Philip Oakley
2013-02-24 15:01 ` W. Trevor King
2013-02-24 22:32 ` Philip Oakley
-- strict thread matches above, loose matches on Subject: below --
2013-02-26 22:56 [PATCH 01/13] Use 'Git' in help messages Philip Oakley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJDDKr4sCBJs_Dq8MdfCJAH4wW7k0TtimW6B01wS6k0zcJ9XHQ@mail.gmail.com \
--to=davvid@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=philipoakley@iee.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).