iris/Iris
1
0
Fork 0
Code Issues 23 Pull requests Projects Releases Packages Wiki Activity Actions

Vault-Sync: Konfliktmarker wurden committet (merge --abort scheitert, Wächter committet halben Merge) #232

New issue
Closed
opened 2026-10-28 17:14:27 +00:00 by alf · 2 comments
alf commented 2026-10-28 17:14:27 +00:00
Owner
Copy link

Beim Test Studio → Mac-VM (iris/Iris#223) landeten Konfliktmarker (<<<<<<< HEAD … >>>>>>> origin/main) in rund 1.050 Notizen im Repo alf/obsidian-vault auf dem Forgejo (Commit 1c5c6754a „Manuelle Änderung“ der VM, 28.10.2026 16:34:55 UTC; weitergegeben mit c6fecfc7c). Das lokale Studio-Vault war nicht betroffen.

Ursache (mit den echten Daten nachgestellt)

  1. mergeRemote führt den Merge aus (merge --no-commit), bekommt 964 Konflikte und nimmt ihn mit git merge --abort zurück.
  2. Der Abbruch scheitert, wenn git beim Zurücksetzen LFS-Dateien laden muss, die auf dem Server fehlen (smudge filter lfs failed; auf der VM fehlen 450 Anhänge), oder wenn eine hinzugefügte Datei vom Index abweicht (Entry … not uptodate. Cannot merge). filter.lfs.required=false war nur beim Merge selbst gesetzt, nicht beim Abbruch.
  3. Das Ergebnis von merge --abort wurde ignoriert: Der Aufruf lieferte „Konflikt“, der Vault blieb mitten im Merge (.git/MERGE_HEAD, Marker im Arbeitsverzeichnis).
  4. Die automatische Sicherung („Manuelle Änderung“, add -A + commit) schrieb den halben Merge als Merge-Commit fest.

Dieselbe Lücke hatte der Linux-Server (_merge_remote, _apply_resolution, vault_git_autocommit). Meine Tests hatten sie nicht gefunden: Dort klappte der Abbruch immer, weil kein Anhang fehlte.

Behoben

  • Abbruch abgesichert (VaultSyncMerge.abortMerge, _abort_merge): erst merge --abort mit nicht-fatalen LFS-Einstellungen, dann reset --hard HEAD (der Vault ist vor jedem Merge sauber, geprüft mit isDirty), zuletzt ohne LFS-Filter. Gelingt nichts davon, meldet der Abgleich einen Fehler (kein „Konflikt“).
  • Kein Commit mitten im Merge: Wächter, Sync-Commit, Notiz-Snapshot und das Commit-Vorbereiten beim Verbinden prüfen .git/MERGE_HEAD (Mac: VaultGitOperations.commitAll/commitPath, commitAllIfNeeded; Linux: _commit_pending, snapshot_note).
  • Konflikte auflösen: checkout --ours/--theirs läuft mit denselben LFS-Einstellungen, damit ein fehlender Anhang eine Datei nicht fälschlich als „gelöscht“ behandelt.

Nicht Teil dieses Issues

  • Reparatur von alf/obsidian-vault (Entscheidung des Nutzers).
  • Die Frage, warum 450 Anhänge auf dem Server fehlen.
Beim Test Studio → Mac-VM (iris/Iris#223) landeten Konfliktmarker (`<<<<<<< HEAD … >>>>>>> origin/main`) in rund 1.050 Notizen im Repo `alf/obsidian-vault` auf dem Forgejo (Commit `1c5c6754a` „Manuelle Änderung“ der VM, 28.10.2026 16:34:55 UTC; weitergegeben mit `c6fecfc7c`). Das lokale Studio-Vault war nicht betroffen. ## Ursache (mit den echten Daten nachgestellt) 1. `mergeRemote` führt den Merge aus (`merge --no-commit`), bekommt 964 Konflikte und nimmt ihn mit `git merge --abort` zurück. 2. Der Abbruch **scheitert**, wenn git beim Zurücksetzen LFS-Dateien laden muss, die auf dem Server fehlen (`smudge filter lfs failed`; auf der VM fehlen 450 Anhänge), oder wenn eine hinzugefügte Datei vom Index abweicht (`Entry … not uptodate. Cannot merge`). `filter.lfs.required=false` war nur beim Merge selbst gesetzt, nicht beim Abbruch. 3. Das Ergebnis von `merge --abort` wurde ignoriert: Der Aufruf lieferte „Konflikt“, der Vault blieb **mitten im Merge** (`.git/MERGE_HEAD`, Marker im Arbeitsverzeichnis). 4. Die automatische Sicherung („Manuelle Änderung“, `add -A` + `commit`) schrieb den halben Merge als Merge-Commit fest. Dieselbe Lücke hatte der Linux-Server (`_merge_remote`, `_apply_resolution`, `vault_git_autocommit`). Meine Tests hatten sie nicht gefunden: Dort klappte der Abbruch immer, weil kein Anhang fehlte. ## Behoben - **Abbruch abgesichert** (`VaultSyncMerge.abortMerge`, `_abort_merge`): erst `merge --abort` mit nicht-fatalen LFS-Einstellungen, dann `reset --hard HEAD` (der Vault ist vor jedem Merge sauber, geprüft mit `isDirty`), zuletzt ohne LFS-Filter. Gelingt nichts davon, meldet der Abgleich einen Fehler (kein „Konflikt“). - **Kein Commit mitten im Merge:** Wächter, Sync-Commit, Notiz-Snapshot und das Commit-Vorbereiten beim Verbinden prüfen `.git/MERGE_HEAD` (Mac: `VaultGitOperations.commitAll/commitPath`, `commitAllIfNeeded`; Linux: `_commit_pending`, `snapshot_note`). - **Konflikte auflösen:** `checkout --ours/--theirs` läuft mit denselben LFS-Einstellungen, damit ein fehlender Anhang eine Datei nicht fälschlich als „gelöscht“ behandelt. ## Nicht Teil dieses Issues - Reparatur von `alf/obsidian-vault` (Entscheidung des Nutzers). - Die Frage, warum 450 Anhänge auf dem Server fehlen.
alf commented 2026-10-28 17:14:38 +00:00
Author
Owner
Copy link

PR #122 gemergt: fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (iris/Iris#232)
iris/iris-linux-server#122

Commits:

  • fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (iris/Iris#232)

Stand 2026-10-28: Korrektur gebaut (Linux-Server und Mac-Server)

  • Befund und Ursache: siehe Beschreibung. Mit den echten Daten nachgestellt: Studio-Repo (22.486 Dateien) in ein Vault mit dem Verlauf des Linux-Servers (2.745 Dateien) zusammengeführt, dabei fehlen LFS-Objekte auf dem Server. Ergebnis vorher: 964 Konflikte, merge --abort scheitert (smudge filter lfs failed), .git/MERGE_HEAD bleibt, 20.959 Einträge gestaged. Ergebnis nachher: 964 Konflikte, kein offener Merge, Vault sauber, kein Commit.
  • Geändert: Linux-Server vault_git_sync.py (_abort_merge, merge_in_progress, Konfliktauflösung mit LFS-Einstellungen), vault_git_autocommit.py (Wächter und Notiz-Snapshot sperren bei MERGE_HEAD); Mac-Server VaultSyncCore.swift (abortMerge, mergeInProgress, Sperre im Commit beim Verbinden), VaultGitOperations.swift (commitAll/commitPath sperren bei MERGE_HEAD).
  • Geprüft: Linux-Server tests/test_vault_git_sync.py und tests/test_vault_sync_routes.py: 90 grün, 1 übersprungen; der neue Test test_failed_merge_abort_still_leaves_the_vault_clean schlägt ohne die Korrektur fehl und besteht mit ihr. Mac-Kern scripts/test-vault-sync-core.sh: 243 Prüfungen, 0 Fehler (neu: scheiternder Abbruch wird aufgefangen, unabbrechbarer Merge wird gemeldet und bleibt gesperrt); Schemes Iris und IrisClient bauen. Nachgestellt mit den echten Daten wie oben (Kopie, nichts am echten Vault).
  • Nicht geprüft: der Ablauf mit echten, vorhandenen LFS-Objekten auf einem echten Forgejo; die Mac-App in der VM (nicht neu installiert); der Mac-Test gegen den alten Code (nur der Linux-Test).
  • Nicht deployt: iris-server und die Mac-VM laufen noch mit dem alten Stand.
  • Offen: Reparatur von alf/obsidian-vault (1.054 Dateien mit Markern im Remote-Stand c6fecfc7c); die VM-Kopie sollte neu aufgesetzt werden; warum 450 Anhänge auf dem Server fehlen.
PR #122 gemergt: fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (iris/Iris#232) https://forgejo.lewerken.duckdns.org/iris/iris-linux-server/pulls/122 Commits: - fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (iris/Iris#232) --- **Stand 2026-10-28: Korrektur gebaut (Linux-Server und Mac-Server)** - **Befund und Ursache:** siehe Beschreibung. Mit den echten Daten nachgestellt: Studio-Repo (22.486 Dateien) in ein Vault mit dem Verlauf des Linux-Servers (2.745 Dateien) zusammengeführt, dabei fehlen LFS-Objekte auf dem Server. Ergebnis vorher: 964 Konflikte, `merge --abort` scheitert (`smudge filter lfs failed`), `.git/MERGE_HEAD` bleibt, 20.959 Einträge gestaged. Ergebnis nachher: 964 Konflikte, kein offener Merge, Vault sauber, kein Commit. - **Geändert:** Linux-Server `vault_git_sync.py` (`_abort_merge`, `merge_in_progress`, Konfliktauflösung mit LFS-Einstellungen), `vault_git_autocommit.py` (Wächter und Notiz-Snapshot sperren bei `MERGE_HEAD`); Mac-Server `VaultSyncCore.swift` (`abortMerge`, `mergeInProgress`, Sperre im Commit beim Verbinden), `VaultGitOperations.swift` (`commitAll`/`commitPath` sperren bei `MERGE_HEAD`). - **Geprüft:** Linux-Server `tests/test_vault_git_sync.py` und `tests/test_vault_sync_routes.py`: 90 grün, 1 übersprungen; der neue Test `test_failed_merge_abort_still_leaves_the_vault_clean` schlägt ohne die Korrektur fehl und besteht mit ihr. Mac-Kern `scripts/test-vault-sync-core.sh`: 243 Prüfungen, 0 Fehler (neu: scheiternder Abbruch wird aufgefangen, unabbrechbarer Merge wird gemeldet und bleibt gesperrt); Schemes Iris und IrisClient bauen. Nachgestellt mit den echten Daten wie oben (Kopie, nichts am echten Vault). - **Nicht geprüft:** der Ablauf mit echten, vorhandenen LFS-Objekten auf einem echten Forgejo; die Mac-App in der VM (nicht neu installiert); der Mac-Test gegen den alten Code (nur der Linux-Test). - **Nicht deployt:** iris-server und die Mac-VM laufen noch mit dem alten Stand. - **Offen:** Reparatur von `alf/obsidian-vault` (1.054 Dateien mit Markern im Remote-Stand `c6fecfc7c`); die VM-Kopie sollte neu aufgesetzt werden; warum 450 Anhänge auf dem Server fehlen.
alf commented 2026-10-28 17:14:41 +00:00
Author
Owner
Copy link

PR #233 gemergt: fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (#232)
#233

Commits:

  • fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (#232)

Stand 2026-10-28: Korrektur gebaut (Linux-Server und Mac-Server)

  • Befund und Ursache: siehe Beschreibung. Mit den echten Daten nachgestellt: Studio-Repo (22.486 Dateien) in ein Vault mit dem Verlauf des Linux-Servers (2.745 Dateien) zusammengeführt, dabei fehlen LFS-Objekte auf dem Server. Ergebnis vorher: 964 Konflikte, merge --abort scheitert (smudge filter lfs failed), .git/MERGE_HEAD bleibt, 20.959 Einträge gestaged. Ergebnis nachher: 964 Konflikte, kein offener Merge, Vault sauber, kein Commit.
  • Geändert: Linux-Server vault_git_sync.py (_abort_merge, merge_in_progress, Konfliktauflösung mit LFS-Einstellungen), vault_git_autocommit.py (Wächter und Notiz-Snapshot sperren bei MERGE_HEAD); Mac-Server VaultSyncCore.swift (abortMerge, mergeInProgress, Sperre im Commit beim Verbinden), VaultGitOperations.swift (commitAll/commitPath sperren bei MERGE_HEAD).
  • Geprüft: Linux-Server tests/test_vault_git_sync.py und tests/test_vault_sync_routes.py: 90 grün, 1 übersprungen; der neue Test test_failed_merge_abort_still_leaves_the_vault_clean schlägt ohne die Korrektur fehl und besteht mit ihr. Mac-Kern scripts/test-vault-sync-core.sh: 243 Prüfungen, 0 Fehler (neu: scheiternder Abbruch wird aufgefangen, unabbrechbarer Merge wird gemeldet und bleibt gesperrt); Schemes Iris und IrisClient bauen. Nachgestellt mit den echten Daten wie oben (Kopie, nichts am echten Vault).
  • Nicht geprüft: der Ablauf mit echten, vorhandenen LFS-Objekten auf einem echten Forgejo; die Mac-App in der VM (nicht neu installiert); der Mac-Test gegen den alten Code (nur der Linux-Test).
  • Nicht deployt: iris-server und die Mac-VM laufen noch mit dem alten Stand.
  • Offen: Reparatur von alf/obsidian-vault (1.054 Dateien mit Markern im Remote-Stand c6fecfc7c); die VM-Kopie sollte neu aufgesetzt werden; warum 450 Anhänge auf dem Server fehlen.
PR #233 gemergt: fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (#232) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/233 Commits: - fix(vault-sync): kein Commit mitten im Merge, Abbruch eines Merge abgesichert (#232) --- **Stand 2026-10-28: Korrektur gebaut (Linux-Server und Mac-Server)** - **Befund und Ursache:** siehe Beschreibung. Mit den echten Daten nachgestellt: Studio-Repo (22.486 Dateien) in ein Vault mit dem Verlauf des Linux-Servers (2.745 Dateien) zusammengeführt, dabei fehlen LFS-Objekte auf dem Server. Ergebnis vorher: 964 Konflikte, `merge --abort` scheitert (`smudge filter lfs failed`), `.git/MERGE_HEAD` bleibt, 20.959 Einträge gestaged. Ergebnis nachher: 964 Konflikte, kein offener Merge, Vault sauber, kein Commit. - **Geändert:** Linux-Server `vault_git_sync.py` (`_abort_merge`, `merge_in_progress`, Konfliktauflösung mit LFS-Einstellungen), `vault_git_autocommit.py` (Wächter und Notiz-Snapshot sperren bei `MERGE_HEAD`); Mac-Server `VaultSyncCore.swift` (`abortMerge`, `mergeInProgress`, Sperre im Commit beim Verbinden), `VaultGitOperations.swift` (`commitAll`/`commitPath` sperren bei `MERGE_HEAD`). - **Geprüft:** Linux-Server `tests/test_vault_git_sync.py` und `tests/test_vault_sync_routes.py`: 90 grün, 1 übersprungen; der neue Test `test_failed_merge_abort_still_leaves_the_vault_clean` schlägt ohne die Korrektur fehl und besteht mit ihr. Mac-Kern `scripts/test-vault-sync-core.sh`: 243 Prüfungen, 0 Fehler (neu: scheiternder Abbruch wird aufgefangen, unabbrechbarer Merge wird gemeldet und bleibt gesperrt); Schemes Iris und IrisClient bauen. Nachgestellt mit den echten Daten wie oben (Kopie, nichts am echten Vault). - **Nicht geprüft:** der Ablauf mit echten, vorhandenen LFS-Objekten auf einem echten Forgejo; die Mac-App in der VM (nicht neu installiert); der Mac-Test gegen den alten Code (nur der Linux-Test). - **Nicht deployt:** iris-server und die Mac-VM laufen noch mit dem alten Stand. - **Offen:** Reparatur von `alf/obsidian-vault` (1.054 Dateien mit Markern im Remote-Stand `c6fecfc7c`); die VM-Kopie sollte neu aufgesetzt werden; warum 450 Anhänge auf dem Server fehlen.
alf 2026-10-31 09:15:19 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
  
herkunft/alpha-feedback
Aus Rückmeldungen der Alpha-Tester

  
status
blockiert
 Wartet auf etwas anderes

  
status
zu-testen
 Gebaut, aber noch nicht im echten Einsatz geprüft

  
typ
bug
 Fehler

  
typ
docs
 Dokumentation

  
typ
enhancement
 Verbesserung einer vorhandenen Funktion

  
typ
feature
 Neue Funktion

  
typ
idea
 Idee, noch nicht entschieden

No labels
herkunft/alpha-feedback
status
blockiert
status
zu-testen
typ
bug
typ
docs
typ
enhancement
typ
feature
typ
idea
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
iris/Iris#232
No description provided.