Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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.
