From 2e27f77b2820ce09983e5045c1777eef6956391c Mon Sep 17 00:00:00 2001 From: Beat Hangartner Date: Sun, 20 Sep 2026 14:21:36 +0200 Subject: [PATCH] Added more verbose description of the difference between lightweight and annotated tags as comment. --- cmake/fetch_kdeaddons.cmake | 13 +++++++++++-- cmake/fetch_pugixml.cmake | 21 ++++++++++++++++++--- cmake/fetch_singleapplication.cmake | 6 +++++- 3 files changed, 34 insertions(+), 6 deletions(-) diff --git a/cmake/fetch_kdeaddons.cmake b/cmake/fetch_kdeaddons.cmake index 7ba66392c..561ed3550 100644 --- a/cmake/fetch_kdeaddons.cmake +++ b/cmake/fetch_kdeaddons.cmake @@ -24,9 +24,18 @@ if(BUILD_WITH_KF) if(BUILD_KF) # v6.10.0 is a more or less random version, taken as an conservative - # approach. Pinned to the commits those tags point at, not to the tags + # approach. Pinned to the commits v6.10.0 points at, not to the tags # themselves; see the note in fetch_pugixml.cmake. Each module lives in its - # own repository, so the same release is a different commit in each. + # own repository, so the same v6.10.0 release is a different commit in + # each. + # + # KDE uses annotated tags, so "git ls-remote 'refs/tags/v6.10.0*'" + # prints two hashes per module: refs/tags/v6.10.0 is the tag object (the + # tagger, the date and the tag message) and refs/tags/v6.10.0^{} is the + # commit that object points at. The hashes below are the "^{}" ones, i.e. + # the commits. Lightweight tags, such as pugixml's v1.15 and + # SingleApplication's v3.2.0, have no tag object and print only the + # commit line. set(KF_ECM_GIT_COMMIT 7dd28cc56c339c3f8fb356f7c53c0e8f61433d81) # v6.10.0 set(KF_KCOREADDONS_GIT_COMMIT c569f974dab24b4784ad186a3db4b76b2fa36612) # v6.10.0 set(KF_KWIDGETSADDONS_GIT_COMMIT 1abbed8a280d6626c59fb197f2c4667d2b1e7445) # v6.10.0 diff --git a/cmake/fetch_pugixml.cmake b/cmake/fetch_pugixml.cmake index 6461701bd..25f235570 100644 --- a/cmake/fetch_pugixml.cmake +++ b/cmake/fetch_pugixml.cmake @@ -44,10 +44,25 @@ if(BUILD_PUGIXML) # is the same one FetchContent relies on here: resolving a git tag at build # time. # - # To upgrade, look up the new tag's commit with git ls-remote - # (for an annotated tag, take the hash on the "^{}" line, which is the - # commit; the other line is the tag object), check that it is the release you + # To upgrade, look up the commit the new tag points at with + # git ls-remote 'refs/tags/*', check that it is the release you # expect, and update both the hash and the trailing tag comment. + # + # How many lines that prints depends on which of the two kinds of tag + # upstream created: + # - A lightweight tag is nothing but a ref pointing straight at the commit, + # so ls-remote prints a single line, "refs/tags/", and its hash is + # the commit to pin. pugixml tags this way, which is why the v1.15 hash + # below is what "git ls-remote ... refs/tags/v1.15" reports directly; + # SingleApplication (v3.2.0) does the same. + # - An annotated tag is a git object in its own right, carrying a tagger, + # a date, a message and optionally a GPG signature, and pointing at the + # commit. ls-remote then prints two lines: "refs/tags/" is the tag + # object and "refs/tags/^{}" is that object dereferenced, i.e. the + # commit. The KDE Frameworks modules tag this way, so for them it is the + # "^{}" hash that belongs in the pin; the other hash identifies the tag + # object itself, which is not the source revision and changes whenever + # upstream re-creates the tag, even over the very same commit. FetchContent_Declare( pugixml GIT_REPOSITORY https://github.com/zeux/pugixml.git diff --git a/cmake/fetch_singleapplication.cmake b/cmake/fetch_singleapplication.cmake index 8685eea43..6983dfc2b 100644 --- a/cmake/fetch_singleapplication.cmake +++ b/cmake/fetch_singleapplication.cmake @@ -32,7 +32,11 @@ if(EXISTS "${CMAKE_SOURCE_DIR}/SingleApplication/CMakeLists.txt") endif() # Pinned to the commit v3.2.0 points at, not to the tag itself; see the note in -# fetch_pugixml.cmake. +# fetch_pugixml.cmake. v3.2.0 is a lightweight tag, a ref pointing straight at +# the commit, so "git ls-remote refs/tags/v3.2.0" prints that commit and +# nothing else. An annotated tag, as KDE uses in fetch_kdeaddons.cmake, would +# print the tag object under refs/tags/v3.2.0 as well, with the commit on the +# refs/tags/v3.2.0^{} line. FetchContent_Declare( SingleApplication GIT_REPOSITORY https://github.com/itay-grudev/SingleApplication.git