A few questions regarding git annotated tags

[Michal Novotny <clime@redhat.com>]

Hello,

I am making an rpm packaging application called rpkg-util
(https://pagure.io/rpkg-util) that can render parts of rpm metadata
from git metadata, e.g. software version. It uses annotated tags to
store most of the data that are then rendered to an rpm spec file
(e.g. the version or changelog).

Now I would like to make sure that I am not omitting some better
approach than the one that I am currently using and for that I would
like to ask the following questions.

I could potentially make it so that I tag subtrees instead of commits
and then derive the needed information from these subtree tags. This
could be useful if I have multiple rpm packages in different subtrees
of the same repo. I could then tag the subtree where the rpm package
is placed.

This could bring some simplification into the code but as far as I
know, you cannot easily checkout a tree tag, which is something a
packager should be able to do easily: to checkout a state of repo when
a certain subpackage was tagged. This is the first question. Can you
e.g. do:

git tag somename HEAD:

and then do something similar to

git checkout somename

which would restore the repository or at least the respective subtree
of it into the state when "somename" tag was created?

Right now, I am putting a package name directly into tag name so I
know what tags belong to what package based on that. And I am using
normal annotated tags. This works quite well, I would say, but at one
point I need to use shared state to move the discovered package name
from one part of the code to another so that the other part can work
with the correct subset of the available annotated tags. I wouldn't
need to do that if I could derive the correct tag subset based just on
the path to the subtree where a package is placed. The path can be
simply an input parameter of all my functions and they could all fetch
the correct tag subset based just on that information. Those functions
are independent of each other, they all derive some information from
the tags but each one is specialized to fetch a different piece of
information. This would be nice. Right now some of my functions accept
name when they need to fetch the associated tag set and work with it
and some accept path if they don't require the tag set.

Alternative approach to creating the tree tags would be to store the
path information into annotated tag message, which I could do. But is
there a relatively simple way to filter tags based on their message
content? Can I put the information into some other part of tag than
name or the message so that it can be easily filtered?

It would be also good if the association of the tags to the subtrees
was made obvious (it will no longer be obvious when it won't depend on
name of the tag) but that's a different problem that I could
potentially solve if I can make the tag<->subtree relation work in
some way. I am pretty happy with the current name-based solution but I
don't want to miss something obvious or less obvious.

Thank you
Michal Novotny