Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

git fetch --tags is blocked by two local tags (pre-rename, v1.5.11) and exits 0 anyway — tag tooling silently reads stale data

Open
  • Is something wrong?
#825 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
38/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
git
Domain
release

Research direction

Inspect the local and origin targets for the pre-rename and v1.5.11 tags before deciding which side is authoritative. Reconcile the tags without blindly forcing an update, then run git fetch --tags origin and scripts/release-gate.mjs to confirm the fetch completes cleanly and the gate produces a real verdict.

Written by the indexing model from the issue text.

Description

git fetch --tags cannot complete in this repo — two local tags block it, and git exits 0 anyway

$ git -C ~/Gits/brainlayer fetch --tags origin
 ! [rejected] pre-rename -> pre-rename  (would clobber existing tag)
 ! [rejected] v1.5.11    -> v1.5.11     (would clobber existing tag)
$ echo $?
0

Two local tags — pre-rename and v1.5.11 — differ from origin's tags of the same name, so git refuses to
update them. It reports the rejections on stderr and still exits 0.

Why this matters beyond an annoyance

Any tooling that fetches tags and trusts the exit code will silently compare against stale local tags.
It will believe the fetch succeeded and answer questions about "the latest release" from data that never
updated. That is not hypothetical: it was found by golems' new release gate
(scripts/release-gate.mjs, golems PR #95), which is why brainlayer is the one repo the gate cannot reach a
verdict for — it returns UNKNOWN, exit 2, deliberately failing closed rather than reporting a
possibly-stale CLEAN.

This is the same shape as several findings this week: a lenient reader standing in for a correctness check.
plutil accepts a plist plistlib rejects; stat succeeds on an iCloud placeholder with no bytes; and
here git fetch --tags returns success while doing only part of its job.

What is needed

Someone who knows the history of these two tags decides which side is authoritative, then reconciles:

  • if origin is authoritative: git fetch --tags --force origin (or delete the local tags first) — but
    check what the local ones point at before discarding them, especially pre-rename, whose name
    suggests it marks a state someone deliberately preserved;
  • if local is authoritative: push them, or rename to stop the collision.

Do not blind-force. Two tags that disagree with origin usually mean someone kept something, and today
this fleet has spent the day on exactly what happens when a cleanup outruns its evidence.

Ask

Reconcile the tag namespace so git fetch --tags completes cleanly. When it does, the release gate will
produce a real verdict for brainlayer instead of UNKNOWN.

Found by the golems release gate on its first live run, 2026-09-09. Filed by the golems lead; owner is the
brainlayer lead.

Dominant language
Python
Stars
9
Forks
7
Avg merge
2h 8m
Merged PRs (30d)
211

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from EtanHey/brainlayer

All issues in EtanHey/brainlayer

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.