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

Re: [PATCH 2/3] sha1_name: get_sha1_with_context learns to follow symlinks

From
David Turner <dturner@twopensource.com>
Date
May 8, 2015, 20:27 UTC
Message-ID
<1431116829.9179.12.camel@ubuntu>
In-Reply-To
<CAPc5daXmJSfdB_eyQ5ppVp2NhYGZvPChGAyn4p2hEde=4x9EEQ@mail.gmail.com>
On Fri, 2015-05-08 at 13:17 -0700, Junio C Hamano wrote:
Show 22 quoted lines
> On Fri, May 8, 2015 at 12:45 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> >> +       if (flags & GET_SHA1_FOLLOW_SYMLINKS && flags & GET_SHA1_ONLY_TO_DIE)
> >> +               die(_("internal error: bad flags for get_sha1_with_context"));
> >
> > There may not be much value in marking an "internal error" string for
> > translation.
> 
> The whole point of this kind of messages is so that the end users,
> when they see it trigger, can notify us and then to allow us to
> identify which die() triggered.  It is not just "may not be much
> value in", but is actively unproductive to make it translatable,
> even if we ignore the cost to i18n/l10n teams to translate such
> messages.
>
> By the way, we would want to standardise the string before the
> colon, so that we can tell users "If you see an error message that
> begins with 'internal error:', please report that to us---it is a
> programming error".  I think the majority of existing code uses the
> string "BUG:" for that, and I do not mind using 'internal error:'
> for that purpose instead, but the important thing is to use just one
> single string thoughout the codebase, so that the "please report
> when you see this" message we give the users can be simple.

It appears that "BUG:" is preferred to "internal error:" by a margin of 2:1. So I'll change it. Fixing the remaining ~40 instances of "internal error" would be a great project for someone new to git development.

>From an i18n perspective, I think the correct thing to do would be to

i18n the "BUG" portion and nothing else. That way, users can understand what has happened, but if they report it upstream, git developers know where in the code to look. But this would probably be complicated to implement, so maybe not worthwhile.

Previous: Junio C HamanoNext: Philip Oakley
Message 8 of 15 in “tree-walk: learn get_tree_enty_follow_symlinks”
  1. 1/3 tree-walk: learn get_tree_enty_follow_symlinksdturner@twopensource.com, May 8, 2015
  2. 2/3 sha1_name: get_sha1_with_context learns to follow symlinksdturner@twopensource.com, May 8, 2015
  3. Eric SunshineMay 8, 2015
  4. Junio C HamanoMay 8, 2015
  5. Junio C HamanoMay 8, 2015
  6. Jeff KingMay 8, 2015
  7. Junio C HamanoMay 8, 2015
  8. David TurnerMay 8, 2015
  9. Philip OakleyMay 8, 2015
  10. Junio C HamanoMay 8, 2015
  11. 3/3 cat-file: add --follow-symlinks to --batchdturner@twopensource.com, May 8, 2015
  12. Eric SunshineMay 8, 2015
  13. Junio C HamanoMay 8, 2015
  14. David TurnerMay 8, 2015
  15. Eric SunshineMay 8, 2015

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.