Thore Cimbal
bae97e6ca6
Decision sorb: option B, a one-time real merge rather than a shared replace ref. What decided it was visibility, not effort - a replace ref works only while everyone remembers to fetch it, and for a repo whose core problem is "git says nothing", a mechanism that silently differs per clone is the wrong shape. The test corrected the option's own description. --allow-unrelated-histories on its own gives a two-way comparison and 1757 conflicts; with the graft set locally it is 32. So the graft is not the alternative to B, it is how B is performed: set it, let the merge compute against it, commit, and the merge commit then carries the real parents so the graft can go. Also recorded because it cost time and looked like a fundamental problem: tags fetched with --depth=1 leave a shallow boundary, so v1.12.26 was walled off at a single commit even though develop carried the same commit in full. Every merge attempt failed with "refusing to merge unrelated histories" until fetch --unshallow. The merge itself is measured but deliberately not executed. apps/web/package.json carries two product decisions rather than conflicts - our Element Call fork against upstream's, and a matrix-js-sdk git pin against a released version - and resolving the first one wrongly would silently delete the noise suppression work from #0054. Neither is safe without a build and the ClamAV functional test.
76 lines
3.5 KiB
Markdown
76 lines
3.5 KiB
Markdown
---
|
|
type: adr
|
|
id: "0022"
|
|
status: accepted
|
|
date: 2026-08-19
|
|
supersedes: null
|
|
superseded_by: null
|
|
related:
|
|
- "docs/issues/0099-threadnet-web-12-upstream-sicherheitsfixes-lassen-sich-nicht-m.md"
|
|
---
|
|
|
|
# ADR-0022: Anschluss an Upstream durch einen einmaligen Merge, nicht durch einen geteilten Graft
|
|
|
|
## Kontext
|
|
|
|
`ThreadNet-Web` enthält keine Upstream-Historie: Am 2026-05-10 kam ein kompletter
|
|
Element-Web-Baum in einem Commit herein. Ohne gemeinsamen Vorfahren ist
|
|
`git merge upstream/develop` unmöglich, und jedes Update bedeutet, zwölf eigene Patches
|
|
von Hand auf einen neuen Baum aufzutragen. Das ist nicht nur mühsam, sondern gefährlich:
|
|
Verschiebt Element eine Datei, verschwinden unsere Zeilen **ohne Konflikt** (#0099).
|
|
|
|
Am 2026-08-19 wurde der tatsächliche Ursprung gemessen statt geraten: **`deadd548`
|
|
vom 2026-05-08** (nicht der Tag `v1.12.17`, wie zuvor angenommen). Der Beleg ist die
|
|
Baumdistanz — 43 abweichende Dateien, davon 31 reine Modus-Änderungen und der Rest
|
|
unser eigenes Feature.
|
|
|
|
Im Wegwerf-Klon getestet: Mit gesetztem Vorfahren läuft ein Merge von drei Monaten
|
|
`develop` durch und erzeugt **32 konfliktbehaftete Dateien, davon nur vier Quellcode** —
|
|
genau unsere Patches.
|
|
|
|
## Optionen
|
|
|
|
**A: Geteilter Replace-Ref.** `git replace --graft` und `refs/replace/*` mitliefern.
|
|
Die Historie bleibt formal unverändert, Git *interpretiert* sie nur anders. Nachteil:
|
|
Jeder Klon braucht einen zusätzlichen Fetch, und wer ihn vergisst, sieht eine andere
|
|
Historie als alle anderen — ein stiller Unterschied, der sich erst im Konfliktfall
|
|
zeigt.
|
|
|
|
**B: Einmaliger echter Merge**, danach normale Merges.
|
|
|
|
⚠️ **Praezisierung nach dem Test:** `--allow-unrelated-histories` allein liefert
|
|
einen ZWEI-Wege-Vergleich und damit 1757 Konflikte — gemessen. Der Graft ist kein
|
|
Gegenentwurf zu B, sondern sein Werkzeug: lokal setzen, den Merge damit rechnen
|
|
lassen (32 Konflikte), committen. Der Merge-Commit traegt danach die echten Eltern,
|
|
der Graft kann weg, und die Abstammung laeuft ueber den Merge-Commit selbst.
|
|
Die Nahtstelle wird ein sichtbarer Merge-Commit. Kein Sonderwissen, kein Zusatzschritt,
|
|
kein Klon kann sie versehentlich übersehen.
|
|
|
|
**C: So weiterarbeiten wie bisher** — Patches von Hand auftragen. Verworfen: Das ist der
|
|
Zustand, der die stille Klasse überhaupt erst erzeugt.
|
|
|
|
## Entscheidung
|
|
|
|
**Option B** (sorb, 2026-08-19).
|
|
|
|
Ausschlaggebend ist nicht der Aufwand — beide Wege sind ähnlich billig — sondern die
|
|
Sichtbarkeit. A funktioniert nur, solange alle daran denken; B trägt sich selbst. Für
|
|
ein Repo, dessen Kernproblem „Git meldet nichts" ist, wäre ein Mechanismus, der
|
|
stillschweigend unterschiedlich wirkt, die falsche Wahl.
|
|
|
|
`deadd548` bleibt trotzdem wichtig: Es ist der Stand, gegen den der Merge gefahren wird,
|
|
und ohne diese Messung wäre der Merge auf eine erfundene Grundlage gelaufen.
|
|
|
|
## Konsequenzen
|
|
|
|
- Der erste Merge ist ein einmaliger Kraftakt mit vier Quellcode-Konflikten; danach ist
|
|
ein Upstream-Update ein gewöhnlicher Merge.
|
|
- **Die stille Klasse verschwindet**: Verschiebt Upstream eine Datei, die wir angefasst
|
|
haben, meldet Git künftig einen Konflikt, statt unsere Zeilen wortlos fallen zu lassen.
|
|
- Die Nahtstelle bleibt als Merge-Commit dauerhaft sichtbar — gewollt, nicht geduldet.
|
|
- **Abnahme ist kein Build, sondern ein Funktionstest**: Die ClamAV-Patches liegen in der
|
|
Medien-Pipeline. Ohne den Test aus #0099 (verschlüsselte Datei senden, abgelehnte
|
|
empfangen) ist der Merge nicht abgenommen.
|
|
- Schritt 4 aus #0099 — ein Verfahren zum Auftragen der Patches — wird damit
|
|
gegenstandslos.
|