Repository navigation
Commit 4816529
authored
fix(changelog): one section per repo, so shared submodules aren't repeated (#1461)
* fix(changelog): one section per repo, so shared submodules aren't repeated
aw-webui is a submodule of aw-server, aw-server-rust and aw-tauri, and the
generator walked the tree recursively, so it got a full section under each of
them: the v0.14.0b8 notes list the same four aw-webui commits three times.
Cleaning that up by hand is what the script's docstring told you to do, and
what was done for v0.12.0/v0.13.0.
Collect the submodule tree first, keyed by repo name, then render one flat
section per repo in `repo_order` (which is what the hand-edited v0.13.0 notes
look like). Parents that only bumped a submodule now drop out entirely instead
of leaving an empty aw-server header.
When parents point at *different* commits of a shared submodule, the section
covers the union of the ranges (`git log tip1 tip2 --not base1 base2`) and
carries a warning naming what each parent pinned, so a desync shows up in the
release notes instead of silently picking one parent's range. Since each parent
has its own clone, the log runs in whichever checkout resolves the most
pointers, and anything unresolvable is called out with a hint to
`git submodule update --init --recursive`.
Also drops the dead `remove_duplicates` FIXME (never called, "doesn't work"),
adds the newer repos to `repo_order`, and covers the above with tests on a
throwaway nested-submodule repo. Output for repos without submodules (gptme) is
byte-identical.
* fix(changelog): compute the real union, and notice parents that never bumped
Review findings on the first commit, all three of them real:
- `tip1 tip2 --not base1 base2` is not the union of the ranges. A commit in one
parent's range gets dropped if another parent's *base* already contains it,
which is exactly what happens when the parents started the release on
different commits of the shared submodule. Log each range on its own and merge
by commit id instead (ordering by commit date once there is more than one).
- `git submodule summary` only reports submodules that moved, so the most likely
desync — one parent bumped, another forgotten — produced no warning at all,
because the forgotten parent was never collected. Read the current pins from
the index separately (`collect_pins`), so every parent that vendors the repo
is named in the warning whether or not it moved.
- out-of-sync now compares those pins rather than whole ranges, so parents that
started apart and converged no longer get a warning claiming they differ while
showing identical commits.
Also: `_pick_checkout` returns None instead of a path that may not exist (an
uninitialized submodule used to crash the run), and the repeated `hidden > 1`
test CodeQL flagged is gone.
Two new tests cover the dropped-commit and never-bumped cases; both fail on the
previous commit. Regenerating v0.14.0b8 gives byte-identical output to before,
as does gptme (no submodules).
* fix(changelog): don't replay a newly-vendored repo, don't drop unresolvable ones
Second review round, two more real ones:
- a parent that adopts a submodule mid-release has no range of its own, so
merging its unbounded log with another parent's bump replayed the submodule's
entire history into the release notes. Prefer the bounded ranges when there
are any; a submodule that is new to *every* parent still lists everything, as
before.
- when no checkout can resolve a repo's pointers (a shallow clone whose base
commit is gone, say), the repo vanished from the notes with only a log line.
It now gets its section and the "could not resolve" note, which was the point
of that note.
Both cases fail on the previous commit.
* fix(changelog): bound a new pin instead of dropping it, keep warnings on filtered repos
Third review round:
- bounding the newly-vendored parent by dropping its range threw away commits
that only its pin has (it may adopt the repo at a commit ahead of what the
other parents bumped to). Bound it by where the parents that already had it
started the release instead, so every pinned commit is covered — which is what
the out-of-sync note promises.
- a repo whose only commits this release are filtered (build/ci) has no entries,
so the section was dropped along with its out-of-sync warning — exactly when
the mismatch is least visible otherwise. A repo that moved now keeps its
section for the warning alone; one that didn't move stays silent.
Both fail on c58d278.
* fix(changelog): resolve each range in a checkout that has it, guard uninitialized dirs
Fourth review round:
- an uninitialized submodule leaves an empty directory, and git commands run there
answer for the *superproject*: `git ls-files --stage` reports the gitlink itself
as "./", so `collect_pins` recursed on ever-longer paths (the string-keyed `seen`
never matched) until it hit RecursionError. Check that a directory is its own
checkout before reading pins from it.
- adoption with no accompanying bump left `bounded` empty, so the unbounded range
survived and replayed the repo's whole history. Bound the pins by where the
parents that already had it sit, whether or not anything was bumped; a repo new
to every parent still lists everything.
- ranges are now resolved one at a time, each in a checkout that holds it
(preferring the clone of the parent it came from), rather than all from one
"best" checkout. With shallow clones holding disjoint histories, commits that
are available somewhere are no longer reported as unavailable everywhere.
Three of the four are Codex's, the adoption one is Greptile's. All fail on b9fe835.1 parent 0daeb23 commit 4816529
3 files changed
Lines changed: 772 additions & 127 deletions
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
| 1 | + | |
| 2 | + | |
| 3 | + | |
| 4 | + | |
| 5 | + | |
| 6 | + | |
| 7 | + | |
| 8 | + | |
| 9 | + | |
| 10 | + | |
| 11 | + | |
| 12 | + | |
| 13 | + | |
| 14 | + | |
| 15 | + | |
| 16 | + | |
| 17 | + | |
| 18 | + | |
| 19 | + | |
| 20 | + | |
| 21 | + | |
| 22 | + | |
| 23 | + | |
| 24 | + | |
| 25 | + | |
0 commit comments