Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> On Sat, Apr 02 2022, Jean-Noël Avila via GitGitGadget wrote:
>
>> From: =?UTF-8?q?Jean-No=C3=ABl=20Avila?= <jn.avila@xxxxxxx>
>>
>> The messages are split into the ones for ref-filter which deal with
>> atoms and scalar which has an option.
>
> I see the git-for-each-ref manpage doesn't really refer to these
> consistently, but I tihnk s/atom/format/g or s/atom/name/g would be lot
> more obvious, especially in the context of how these are already
> discussed in the manpage.
I do not necessarily think so, even though "atom" is a word that
directly faces those who wrote the code in for-each-ref.c that have
been moved to ref-filter.c and not the end users.
These are only parts of a string that is given to --format=..., so
"format" makes it more confusing than even the original.
I can buy
'%(objectype)' in format does not take arguments
though. If you did not find a specific word to refer to these
"field names" that the documentation consistently uses, it is a way
to clarify which '%(objecttype)' we are referring to, without having
to commit to a single word.
Or we can call them "field names" like the documentation calls them,
which would make it into
field name '%(objecttype)' does not take arguments
which is not too bad, but I somehow find the former (i.e. "X in
format string does not take arguments") probably the easiest to
follow, if you want to change the original.
Just my 2 yen.
>> @@ -317,7 +317,7 @@ static int objecttype_atom_parser(struct ref_format *format, struct used_atom *a
>> const char *arg, struct strbuf *err)
>> {
>> if (arg)
>> - return strbuf_addf_ret(err, -1, _("%%(objecttype) does not take arguments"));
>> + return strbuf_addf_ret(err, -1, _("the atom '%s' does not take arguments"), "%(objecttype)");
>> if (*atom->name == '*')
>> oi_deref.info.typep = &oi_deref.type;
>> else
