Given / When / Then
Given the release-cut model where dev is squash-merged to main and a vN.N.N tag is then created,
When the tag is placed on the release-branch HEAD (the pre-squash commit) instead of the squash commit that actually landed on main,
Then the tag points off main's ancestry — git describe --tags upstream/main fails with "No tags can describe …", git merge-base --is-ancestor <tag> upstream/main is false, and "fork from the latest release" / git describe-based tooling breaks.
This is the current state of v2.3.0 on the framework repo: the tag commit is not in main's history (the real v2.3.0 release commit on main is a different SHA). v3.0.0 was tagged correctly (on upstream/main), so the two coexist inconsistently.
Repro
git fetch upstream --tagsgit describe --tags --abbrev=0 upstream/main → fails: No tags can describe ''.git merge-base --is-ancestor v2.3.0 upstream/main; echo $? → non-zero (not an ancestor).- By contrast
git merge-base --is-ancestor v3.0.0 upstream/main; echo $? → 0.
Expected
The /release tagging step must tag the merged commit on main (git tag vN.N.N upstream/main after the release PR squash-merges), never the release-branch HEAD. Worth adding a guard/post-check: after tagging, assert git merge-base --is-ancestor vN.N.N upstream/main and warn if false. The existing mis-placed v2.3.0 tag should also be re-pointed at its real squash commit on main.
Environment
- ApexYard framework,
/release skill (tag + push step) and/or manual release tagging
- Observed on
me2resh/apexyard: v2.3.0 off-ancestry, v3.0.0 correct.
Severity
Medium — breaks git describe, "default to latest release" assumptions, and any ancestry-based tooling; not data-affecting. Fix is a tagging-target correction + a one-time re-point of v2.3.0.
Glossary
| Term |
Definition |
| Squash commit |
The single commit created on main when a release PR is squash-merged; the tag must point here. |
Ancestry / git describe |
Tag discoverability depends on the tag being a reachable ancestor of the branch tip. |
Given / When / Then
Given the release-cut model where
devis squash-merged tomainand avN.N.Ntag is then created,When the tag is placed on the release-branch HEAD (the pre-squash commit) instead of the squash commit that actually landed on
main,Then the tag points off
main's ancestry —git describe --tags upstream/mainfails with "No tags can describe …",git merge-base --is-ancestor <tag> upstream/mainis false, and "fork from the latest release" /git describe-based tooling breaks.This is the current state of
v2.3.0on the framework repo: the tag commit is not inmain's history (the real v2.3.0 release commit on main is a different SHA).v3.0.0was tagged correctly (onupstream/main), so the two coexist inconsistently.Repro
git fetch upstream --tagsgit describe --tags --abbrev=0 upstream/main→ fails: No tags can describe ''.git merge-base --is-ancestor v2.3.0 upstream/main; echo $?→ non-zero (not an ancestor).git merge-base --is-ancestor v3.0.0 upstream/main; echo $?→ 0.Expected
The
/releasetagging step must tag the merged commit onmain(git tag vN.N.N upstream/mainafter the release PR squash-merges), never the release-branch HEAD. Worth adding a guard/post-check: after tagging, assertgit merge-base --is-ancestor vN.N.N upstream/mainand warn if false. The existing mis-placedv2.3.0tag should also be re-pointed at its real squash commit onmain.Environment
/releaseskill (tag + push step) and/or manual release taggingme2resh/apexyard:v2.3.0off-ancestry,v3.0.0correct.Severity
Medium — breaks
git describe, "default to latest release" assumptions, and any ancestry-based tooling; not data-affecting. Fix is a tagging-target correction + a one-time re-point ofv2.3.0.Glossary
mainwhen a release PR is squash-merged; the tag must point here.git describe