>> >> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
