Re: [PATCH v3 4/5] Always check `parse_tree*()`'s return value

[Junio C Hamano <gitster@pobox.com>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:

> Right. I had used
>
>   $ git grep 'unable to read tree .*%s' | sed -n 's/.*_("\([^"]*\).*/\1/p' | sort | uniq -c
>        11 unable to read tree %s
>         3 unable to read tree (%s)
>
> only to realize that the 11 were the ones I added.🤦 Re-running the same
> command on v2.43.0 reports only the 3 parenthesized ones.

I think we probably should discuss what format is the easiest to
understand and most logical to readers, and unify to such a format,
not necessarily the current majority, in the longer term.  But for
now, let's pick one that costs less to unify to.

We may also want to cast a wider net to make things consistent.  For
example, we learn that the parenthesized one is not necessarily more
prevalent in a larger picture.

Let me annotate the output from this command:

    $ git grep -h -E \
      -e '(unable to|not) (read|find|acccess) (blob|tree|commit|tag) .*%s' master po/ |
      sort -u

1. msgid "cannot find commit %s (%s)"

   The first one is a textual refname, the next one is oid-to-hex.

2. msgid "cannot read blob %s for path %s"

   The first one is oid-to-hex, the other is a pathname.

3. msgid "could not find commit %s"

   oid-to-hex (in commit-graph.c)

4. msgid "could not read commit message of %s"

   oid-to-hex (in sequencer.c)

5. msgid "could not read commit message: %s"

   This is irrelevant to the topic, as %s is for strerror().

6. msgid "unable to access commit %s"

   oid-to-hex (in builtin/pull.c)

7. msgid "unable to read commit message from '%s'"

   This message is in po/ but it seems that it no longer is used
   anywhere in the source.

8. msgid "unable to read tree %s"
9. msgid "unable to read tree (%s)"

   We know about these two already.

We seem to just use unadorned %s for many messages when talking
about commit objects, some are inside a pair of 'single quotes',
When we are giving a long hexadecimal string, especially without
doing any abbreviation, I personally think it is a waste to enclose
it in any punctuation pair, so if I were to vote today, I would
probably support standardizing on "tree %s", "blob %s", etc., but I
think that is just a personal preference (not even a "taste" thing).

In any case, all of the above is clearly outside the scope of this
series.