Files changed: - kb/concepts/Delete Rather Than Anonymize.md - kb/concepts/Publish-Remote Gate.md - kb/entities/projects/Chemenu.md - kb/entities/tools/wikitool.md - kb/index.md - kb/log.md - kb/provenance.md - kb/sources/INDEX.md - kb/sources/Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01.md
4.4 KiB
type, source_type, author, raw_files, source_language, date, tags, entities, concepts, summary
| type | source_type | author | raw_files | source_language | date | tags | entities | concepts | summary | |||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| types/source.md | notes | Torben |
|
de | 2026-09-01 |
|
|
Sitzung, die eine ungeprueft niedergeschriebene Merge-Behauptung in private-instance.md durch einen empirischen Test widerlegt, die Prozedur korrigiert (2.2.1) und Issue #30 mit einem getesteten Skript sowie zwei Architekturvorschlaegen anlegt. |
Source: Private-Instance Merge Correction and Issue 30 Session 2026-09-01
Autor: Torben
Datum: 2026-09-01
Raw-Dateien: raw/notes/Conversation Transcript - Private-Instance Merge Correction and Issue 30 Session 2026-09-01.md
Typ: Notes
Zusammenfassung
Torben fragte, was in der privaten Instanz nach dem beschriebenen Schema passiert, wenn Upstream
den Demo-Korpus ändert - eine Frage, die eine am selben Tag geschriebene, aber nie getestete
Behauptung in instructions/private-instance.md traf. Statt die bestehende Textstelle zu
verteidigen, wurde sie an einem Wegwerf-Repo-Paar empirisch geprüft: Ein git merge upstream/main löst eine geänderte, gelöschte Demo-Seite nicht still auf, sondern erzeugt
einen modify/delete-Konflikt und lässt die Upstream-Fassung im Arbeitsbaum liegen; eine neu
angelegte Demo-Seite wird dagegen stillschweigend gestaged, ohne Konflikt und ohne Meldung.
Ein zweiter, naheliegender Fix (.gitattributes mit merge=ours für die Inhaltsverzeichnisse)
wurde ebenfalls getestet und ebenfalls widerlegt - der Treiber wirkt nur bei Inhaltskonflikten
auf beidseitig vorhandenen Dateien, nicht bei modify/delete oder Neuanlage.
Die Instruktion wurde korrigiert (Version 2.2.1): Der Merge wird mit --no-commit offengehalten,
die Inhaltsverzeichnisse werden auf den Stand vor dem Merge zurückgezwungen, solange HEAD noch
dorthin zeigt, erst dann wird committet - gefolgt von einer Kontrolle
(git diff --name-only $BEFORE HEAD -- kb raw muss leer sein), die nicht stillschweigend
übersprungen werden kann. Ein eigenständiges, getestetes Skript wurde daraus abgeleitet und in
Issue #30 hinterlegt, zusammen mit zwei Architekturvorschlägen: das Verfahren als wikitool-
Kommando statt als Shell-Rezept, oder - als eigentliche Ursachenbehebung - den Demo-Korpus
grundsätzlich von dem Branch fernzuhalten, von dem private Instanzen ihre Maschinerie ziehen.
Anschließend wurde Issue #3 (Chemenu-Rebranding) gegen seine eigenen Abnahmekriterien geprüft
und für sauber befunden, und eine Verdrahtungslücke geschlossen (tools/CONTRACT.md kannte das
Publish-Remote-Gate nicht, gates.md verlinkte nicht auf die Prozedur, die Chemenu-Projektseite
beschrieb sich noch als privates Wiki) - veröffentlicht als 2.2.2.
Kernaussagen
- Eine Behauptung über Git-Merge-Verhalten ist erst nach einem Test eine Tatsache. Am selben Tag geschrieben zu haben ist kein Beleg für Richtigkeit.
git mergebehandelt "eine Datei geändert" und "eine Datei neu angelegt" unterschiedlich: Nur Ersteres erzeugt einen sichtbaren Konflikt. Eine Prozedur, die nur den Konfliktfall bedenkt, übersieht die stille Neuanlage..gitattributes-Merge-Treiber wiemerge=ourswirken nur auf Inhaltskonflikte zwischen beidseitig vorhandenen Dateiversionen, nicht auf modify/delete-Paare oder Neuanlagen.- Eine Kontrollprüfung, die ein Mensch lesen und verstehen muss, um einen Fehler zu bemerken, ist schwächer als eine, die bei einem Fehler selbst nicht-null zurückgibt.
- Wiederkehrende Symptome bei jeder Downstream-Instanz sind oft ein Zeichen, dass die eigentliche Ursache stromaufwärts liegt und dort einmalig behoben werden sollte.
Aufgaben
private-instance.mdkorrigiert und als 2.2.1 veröffentlicht- Issue #30 angelegt (Skript + zwei Architekturvorschläge, hängt an #28)
- Issue #3 gegen Abnahmekriterien geprüft, sauber
- Issue #30 selbst ist offen - siehe dort für den Entscheidungsstand
Nicht übernommen
- Die im Transkript vollständig gezeigten Testskript-Läufe (Shell-Ausgabe der Wegwerf-Repos) sind hier nicht wiederholt - die Kernaussage (welches Verhalten gemessen wurde) ist auf die Concept-Seite Publish-Remote Gate und in Issue #30 übernommen, der Beleg bleibt im Transkript.