thoralf
released this
2026-10-19 20:41:16 +02:00
| 22 commits to main since this release
Changed
- Merged upstream Phanpy — 2 commit(s) (see
CHANGELOG.phanpy.md for upstream detail):
63d26fda Upgrade deps2a801b1e Only generate used icons
- The conflict-candidate list is read from
.gitattributes instead of a fixed
list of files. Upstream edits its own CHANGELOG.md regularly and merge=ours
resolves that without a human, so the hardcoded version would have announced a
conflict candidate on most runs — the noise that makes a real one invisible.
Fixed
merge=ours can no longer silently discard your change. The fork-owned files
(README, CHANGELOG, LICENSE, SECURITY, PRIVACY) must keep our version on an upstream
merge — but git calls that driver for every three-way merge, and on a rebase or
cherry-pick "ours" is the branch being replayed onto while "theirs" is your commit.
The built-in true therefore threw your change away, silently: it did exactly that
three times on 2026-10-18/19 (both prod cherry-picks and one rebase, each losing a
CHANGELOG entry), with no conflict and nothing in the diffstat to catch the eye.
scripts/phandroid-merge-ours.sh replaces it: it still keeps ours, but writes the
discarded version to .git/phandroid-dropped/<path> and names it on stderr, so the
loss is visible while it happens and recoverable afterwards. It needs the driver once
per clone (git config merge.phandroid-ours.driver …; the workflow declares it for
CI), and a clone without it now gets a visible conflict instead of silence.- The lockfile guard fails closed. Input it cannot check — a lockfile without a
packages map (lockfileVersion 1), an unparsable or missing file — now stops the
run with one line naming the file and the reason (exit 2), instead of comparing
zero entries and reporting a green "0 upstream entries unchanged". A guard that
validates nothing is the failure mode this pipeline keeps hitting: an unmatched
test glob ran zero tests and exited 0, and the awk the changelog bump replaced
exited 0 on a missing [Unreleased] heading. Only exit 0 means the invariant held.
- A release section no longer carries two
### Changed headings. The generated
upstream-merge block was followed by the moved hand-written entries including
their own ### Changed, so a release whose entries had one showed that heading
twice — in the release body on both instances (2.0.80 shipped that way) and, for
sections short enough to survive the 500-character limit, twice as "Changed:" in
the F-Droid "What's New" text (measured against the pre-fix script; in 2.0.80 the
truncation dropped the second block, so there only the release body showed it).
Hand-written ### Changed bullets now merge into the generated block, which stays
first because the upstream merge is the release's headline; every other
hand-written section keeps its place. A body without a ### Changed heading still
produces byte-identical output — verified against the pre-fix script over six
input shapes. A heading spelled with extra whitespace (### Changed) counts as
the same heading, and a body of nothing but headings no longer counts as fork
changes: it used to append a stray empty heading and drop the "no Android-fork
code changes" claim for a release that had none.
Downloads