Hi,
Hariom verma <hariom18599@xxxxxxxxx> 于2021年6月28日周一 下午3:47写道：
>
> Hi,
>
> >
> > Most of the atoms in `for-each-ref --format` are now supported,
> > such as `%(tree)`, `%(parent)`, `%(author)`, `%(tagger)`, `%(if)`,
> > `%(then)`, `%(else)`, `%(end)`. But these atoms will be rejected:
> > `%(refname)`, `%(symref)`, `%(upstream)`, `%(push)`, `%(worktreepath)`,
> > `%(flag)`, `%(HEAD)`, because our objects don't have a refname.
>
> It's not clear why some atoms are rejected?
>
> Are we going to support them in later commits? (or sometime in the future)
> OR
> We are never going to support them. Because they make no sense to
> cat-file? (or whatever the reason)
>
Because in "git for-each-ref"'s "family", ref_array_item is generated
by filter_refs(),
which uses ref_filter_handler() to fill ref_array_item with ref's
data. In "git cat-file",
we care about the object, not the ref. Therefore, ref_array_item is
only filled with
{oid, rest} in batch_object_write() in cat-file.c. We cannot represent
some specific
ref-related data in "git cat-file", so we cannot have some atoms in ref_filter.
Yes, we probably won't support them in the future.
>From an object-oriented point of view, the atom supported by
"cat-file" should be a
parent class, "for-each-ref"',"branch","tag"... they have more
specific object details (ref),
their supported atom should be a derived class, they can support more atoms.
> Whatever is the reason, I think it's a good idea to include it in the
> commit message.
>
Yeah. The sentence "because our objects don't have a refname." may not
correctly express the reason for rejecting these atoms. I will add
more descriptions.
> --
> Hariom
Thanks.
--
ZheNing Hu
