Tags can also be added retroactively and backdated. These things conflict with the advantages you list (in particular, with NVR auto-generation, git is not the sole source of truth).
If the tag ordering function is done properly, I believe even retroactive tagging (i.e. tagging into past) and/or tag backdating would be supported and NVR auto-generation would work correctly. So I don't think it needs to conflict. But can you perhaps expand more on "Tags can also be added retroactively and backdated", please? I.e. why/when would one do that.
No, you can push tags with incorrect dates. This can change the auto-generation.
It really depends on what the tag ordering function is. If the function does not consider dates at all, this wouldn't be a problem.
The commit graph is ordered, but everything else is not. Tags (whether annotated or not) are outside the commit graph, so their order is not fixed.
I think this is different with Mercurial, where tags are part of the commit graph.
You can only avoid this if you use data from commits (both current and earlier) *on the same branch* exclusively for generating metadata (or hash-linked from there). Everything else can get of sync and change over time even if the commit hash stays the same, so the repository state at a specific commit hash is longer the sole source of truth. (Because you need to reconstruct that other state *at the right time*.)
What do you mean by "everything else which can get out of sync and change"? If you are talking about tags (or refs in general), it's true that you can add tags into past which may or may not affect auto-generation depending on the ordering function.
What kind of ordering function could tell apart a retroactively added tag and one that was there when the build was submitted?
That's why I proposed to auto-generate release numbers and changelogs based on the commits going back to the last Release: line and %changelog section update in the spec file. That would be stable (unless the tool changes how it generates those spec file parts).
I don't think you can automatically generate %changelog and Release and at the same time base their auto-generation on their last change in spec file in git history. That somehow doesn't seem that it would work.
I don't know of any problems, and I have implemented this in the past (although in a very different context).
Tagging into past is imho rather a theoretical use-case but useful to consider.
Is it? It can easily happen if you forget to push a tag and then do a build, and push it later.
Thanks, Florian