git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 01/13] Use 'Git' in help messages

From
David Aguilar <davvid@gmail.com>
Date
Feb 24, 2013, 22:11 UTC
Message-ID
<CAJDDKr4sCBJs_Dq8MdfCJAH4wW7k0TtimW6B01wS6k0zcJ9XHQ@mail.gmail.com>
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:
Show 15 quoted lines
> 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
Previous: Philip OakleyNext: Philip Oakley
Message 7 of 37 in “Git help option to list user guides”
  1. 00/13 Git help option to list user guidesPhilip Oakley, Feb 23, 2013
  2. 01/13 Use 'Git' in help messagesPhilip Oakley, Feb 23, 2013
  3. David AguilarFeb 23, 2013
  4. Philip OakleyFeb 23, 2013
  5. Junio C HamanoFeb 24, 2013
  6. Philip OakleyFeb 24, 2013
  7. David AguilarFeb 24, 2013
  8. 02/13 Show 'git help <guide>' usage, with examplesPhilip Oakley, Feb 23, 2013
  9. W. Trevor KingFeb 24, 2013
  10. Philip OakleyFeb 24, 2013
  11. 03/13 Help.c use OPT_COUNTUPPhilip Oakley, Feb 23, 2013
  12. 04/13 Help.c add --guide optionPhilip Oakley, Feb 23, 2013
  13. 05/13 Help.c: add list_common_guides_help() functionPhilip Oakley, Feb 23, 2013
  14. Junio C HamanoFeb 24, 2013
  15. Philip OakleyFeb 24, 2013
  16. Junio C HamanoFeb 25, 2013
  17. Philip OakleyFeb 25, 2013
  18. Junio C HamanoFeb 25, 2013
  19. 06/13 Add guide-list.txt and extraction shellPhilip Oakley, Feb 23, 2013
  20. W. Trevor KingFeb 24, 2013
  21. Philip OakleyFeb 24, 2013
  22. 07/13 Extend name string for longer namesPhilip Oakley, Feb 23, 2013
  23. 09/13 Rename everyday to giteverydayPhilip Oakley, Feb 23, 2013
  24. W. Trevor KingFeb 24, 2013
  25. Philip OakleyFeb 24, 2013
  26. 10/13 Update Git(1) links to guidesPhilip Oakley, Feb 23, 2013
  27. 11/13 Add missing guides to list and regeneratePhilip Oakley, Feb 23, 2013
  28. 12/13 Documentation/Makefile: update git guide linksPhilip Oakley, Feb 23, 2013
  29. W. Trevor KingFeb 24, 2013
  30. Philip OakleyFeb 24, 2013
  31. Junio C HamanoFeb 25, 2013
  32. Philip OakleyFeb 25, 2013
  33. Junio C HamanoFeb 26, 2013
  34. Philip OakleyFeb 26, 2013
  35. 13/13 Fixup! doc: giteveryday and user-manual man formatPhilip Oakley, Feb 23, 2013
  36. W. Trevor KingFeb 24, 2013
  37. Philip OakleyFeb 24, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.