Files
chemenu/kb/sources/Source - Private-Instance Merge Correction and Issue 30 Session 2026-09-01.md
T
torben d1cf2e0327 ingest: Private-Instance Merge Correction and Issue 30 Session 2026-09-01
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
2026-09-01 20:36:01 +02:00

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
raw/notes/Conversation Transcript - Private-Instance Merge Correction and Issue 30 Session 2026-09-01.md
de 2026-09-01
Chemenu
wikitool
Publish-Remote Gate
Delete Rather Than Anonymize
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 merge behandelt "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 wie merge=ours wirken 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.md korrigiert 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.

Verwandte Entities

Verwandte Concepts