From 685fc2e15e64f572e4c6d189daac28ca2c6b157b Mon Sep 17 00:00:00 2001 From: Torben Nehmer Date: Sat, 26 Sep 2026 15:49:23 +0200 Subject: [PATCH] docs: CHANGES entry for #144 in English, heading matches its bump title Files changed: - CHANGES.md --- CHANGES.md | 36 +++++++++++++++--------------------- 1 file changed, 15 insertions(+), 21 deletions(-) diff --git a/CHANGES.md b/CHANGES.md index f126bf4..9cc2133 100644 --- a/CHANGES.md +++ b/CHANGES.md @@ -359,28 +359,22 @@ byte-identical to before. `cli.py`'s and `_util.py`'s lookup of the running comm `cli_contract` path is now one shared function, `cli_contract.path_of`, in place of a private copy that used to live only in `cli.py`. -### network: Eigenschaft definiert; sync, publish und upstream merge als netzwerkend markiert +### network: property defined; sync, publish and upstream merge marked networked -Gitea #144: `network:` blieb undefiniert und stand mit dem Code sowie mit sich selbst im -Widerspruch. `sync` und `publish` (`git_publish.py`) sowie `upstream merge` (`upstream_cmd.py`) -sprechen ein Git-Remote an (`fetch`, `ls-remote`, `push`), trugen aber `network: no`; `upstream -verify` liest nur bereits geholte Refs und bleibt zu Recht bei `no`. Gleichzeitig behauptete -`version check`s Datensatz, mit `version notes` eines von nur zwei netzwerkenden Kommandos in -`wikitool` zu sein - während `review`, `task new`/`task list`/`task close` und `doctor` seit -Gitea #121 ebenfalls `network: yes` tragen. Drei weitere Docstrings wiederholten dieselbe -Ausschließlichkeit: der Modul- und der Befehls-Docstring von `version_cmd.py` sowie -`fetch_latest`s Docstring in `version.py`, dessen Behauptung „the one place that talks to a -remote host" auch unter der bisherigen, engen Lesart falsch war, da `tasks/caldav.py` und -`tasks/superproductivity.py` ebenfalls per `urllib` sprechen. - -Entschieden (Operator, 2026-09-26): `network:` meint jeden Netzzugriff, gleich ob per HTTP aus -`wikitool` selbst oder per Git-Operation gegen ein Remote - maßgeblich ist, was möglich ist, -nicht was im Normalfall passiert, und ein Git-Aufruf, der nur lokale Refs liest, zählt nicht. -Diese Bedeutung steht jetzt im Docstring von `cli_contract.Network`. `sync`, `publish` und -`upstream merge` tragen `network: yes`; alle vier überzähligen bzw. falschen Textstellen sind -korrigiert, ohne eine neue Zahl zu behaupten. Ein neuer Test schreibt die Menge der `network: -yes`-Pfade explizit fest, damit ein künftiger Wechsel eine bewusste Teständerung ist statt -stillen Auseinanderlaufens. +The `network:` property had no written meaning, and the records disagreed with the code and with +each other. `sync`, `publish` and `upstream merge` talk to a git remote (`fetch`, `ls-remote`, +`push`) but said `network: no`, while `version check`'s record called itself one of only two +networked commands - next to `review`, `task new`/`list`/`close` and `doctor`, all of which +already said `yes`. `cli_contract.Network` now carries the meaning: `yes` when at least one path +through the command can reach an endpoint outside the checkout, by an HTTP call of `wikitool`'s +own or by a git operation against a remote; what is possible counts, not what is usual, so +`--offline`, `--no-fetch` or a local-path remote does not turn it back to `no`, and a git call +that only reads refs already on disk is not network access. `sync`, `publish` and `upstream +merge` now say `yes`; `upstream verify` only reads fetched refs and stays `no`. The count claim +is gone from `version check`'s record, from two docstrings in `version_cmd.py`, and from +`version.fetch_latest`, which claimed to be the only place talking to a remote host although the +CalDAV and Super Productivity providers do too. A test over the real registry pins the set of +`network: yes` commands, so a change to it is an edit to that test rather than silent drift. ---