feat(git): laat de notities meereizen naar een repo, en houd ze heel (#541) #673
No reviewers
Labels
No labels
accepted
bug
declined
docs
duplicate
enhancement
good first issue
in-progress
needs-info
privacy
security
triage
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
LibreKAT/Ocideck!673
Loading…
Reference in a new issue
No description provided.
Delete branch "feat/notities-naar-git"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Deel 1 van #541: de notities reizen mee naar een git-repo. Ink en zegel blijven bewust liggen — die wachten niet op werk maar op een ontwerpbesluit (streekidentiteit in het annotatieformaat; wat een zegel betekent op een tak die herschreven kan worden).
Wat er verandert
De notities staan nu als
deck.user-notes.jsonnaastdeck.md, op een vast pad — niet in de op inhoud geadresseerde pool, want daar zou elk getypt teken een nieuw bestand minten en het vorige laten wegkwijnen. Bij het openen hangen ze weer aan de juiste dia, herkend aan de vingerafdruk en niet aan het id (dat wordt bij elke parse opnieuw uitgedeeld).De waarschuwing vóór de commit verliest exact de regel die onwaar werd, en houdt die over tekeningen en het zegel. De regressiepoort die het issue vraagt toetst nu per verhuisde laag dat er niets meer over gemeld wordt — media sinds #515, notities sinds #541.
D7 klopte niet zoals het er stond
Dat ontwerpbesluit zegt dat dit bestand door git's gewone tekst-merge gaat, "so that two authors editing different slides' notes merge cleanly". Maar de sidecar is JSON en
jsonEncodezet die op één regel, en op één regel botst élke wijziging met élke andere. Regelgebaseerd mergen heeft regels nodig.De repo-kopie wordt daarom ingesprongen geschreven, één veld per regel; het bestand op schijf — dat niemand ooit samenvoegt — blijft compact. Beide decoderen identiek, en
FILE_FORMAT§6.3.1 zegt nu expliciet dat een ander werktuig beide vormen mag schrijven.De bewakerreview vond drie manieren om notities kwijt te raken
Alle drie nagemeten voor ik ze aannam, alle drie stil, alle drie ontstaan dóór deze tak — en daarmee slechter dan de waarschuwing die hij vervangt, want dáár wist de gebruiker het.
SyncEngineleidt zijndeletesaf uit wat lokaal ontbreekt. Online opslaan, offline één woord wijzigen, weer online → het notitiebestand van de tak verwijderd, met een groene melding. De inline map in de state-laag is nu één functie met één lijst (mirrorDeckFiles) mét de regel erboven dat wat er niet in staat verwíjderd wordt.mergederfdeuserNotesletterlijk van onze kant, gesleuteld op id's uit onze parse, terwijl de samengevoegde dia's grotendeels uit de basis en van de ander komen. Twee auteurs, notities op verschillende dia's → beider werk weg, status merged.En in de tweede ronde bleek reparatie 2 op het REST-pad te landen terwijl native het pad is dat de app kiest zodra git geïnstalleerd is. Daar kreeg de resolver alleen de
deck.md-bytes van de drie kanten, dus alle drie de decks leken notitieloos — en omdat de deckmap wordt vervangen door wat de resolver teruggeeft, stond het bestand als verwijdering in de merge-commit.mergeRemotegeeft nu eenMergeSideReadermee.In de derde ronde: de regel dekte het verwijderen maar niet het overschrijven. Eén gebruiker, geen merge nodig — een collega schrijft
version: 3, jij ziet geen notities, typt er één, en jouw v2-bestand ging over hun hele bestand heen. De vraag is omgedraaid naar "mag ik hier aan komen", één keer vóór de vertakking, net als_sidecarUntouchableop schijf.Waar de code terechtkwam
De klasseratchet viel twee keer, en had beide keren gelijk. Het hele native oplosblok is
resolveRepoDeckMergein de servicelaag geworden — elke regel erin ging over opslag — en de state-laag levert alleen nog de importpoort en de afbeeldingsresolver.TabsNotifierstaat daarmee 16 regels ónder zijn oude plafond; dat plafond is meeverlaagd. Dat is meteen een hap uit #518.Privacy
Notities kunnen gevoeliger zijn dan de dia's zelf, ze worden door OciWacht bewust niet gescand, en ze belanden nu in een gedeelde repo onder je eigen naam in het commitlog. Dat staat nu waar iemand het leest vóórdat hij typt — in de gids bij de sectie waar je kiest wat je in dit veld zet, niet bij de git-lijst — en het commentaar in
privacy_projection.dartis gecorrigeerd, want dat zei nog dat deze notities "geen enkel exportartefact bereiken".Getoetst
make checkgroen, ook na de rebase op de huidige main.Niet gedraaid:
make check-secretsenmake sast— gitleaks, trufflehog en semgrep staan geen van drieën op deze machine. Deze wijziging voegt geen sleutel, netwerkpad of afhankelijkheid toe, maar de eis is daarmee niet gehaald.Apart gemeld
#670 — een native merge verwijdert
<deckDir>/data/*.json, in de faaltak én bij een geslaagde merge. Dat dateert van vóór deze tak (de grafiekdata liep er al tegenaan) en repareren vraagt een wijziging aan watmergeRemote/_writeAllbeloven over bestanden die de resolver niet noemt.Werkt deel 1 van #541 af; het issue blijft open voor ink en zegel.
Tweede bewakerronde. De vorige reparatie landde op het REST-pad; het native pad is wat de app kiest zodra git geïnstalleerd is, en dáár verdween nog steeds alles. **Waarom het misging.** `mergeRemote` gaf zijn resolver alleen de `deck.md`-bytes van de drie kanten. Een deck is meer dan zijn markdown: de notities staan in een eigen bestand per ref. Alle drie de decks leken dus notitieloos, de merge had niets terug te geven, en omdat de deckmap wordt vervángen door wat de resolver oplevert, stond het notitiebestand als verwijdering in de merge-commit. Twee auteurs met een notitie op verschillende dia's waren beiden alles kwijt — bij het gewoonste scenario dat er is, op de standaardconfiguratie, met status "merged" en zonder melding. `mergeRemote` geeft nu een `MergeSideReader` mee waarmee de resolver elk pad in de deckmap per kant kan lezen (`git show <ref>:<pad>`). Ook het faalgeval draagt nu onze notities: `{deckFile: ourBytes}` heette "onze kant blijft staan zoals hij was" en was dat niet. **Waar het nu woont.** De klasseratchet wees de weg: het hele oplosblok is naar `resolveRepoDeckMerge` in de servicelaag verhuisd. Elke regel erin gaat over opslag — welke lagen een kant draagt, wat er overblijft als het niet lukt, wat de deckmap wordt — en de state-laag levert alleen wat zij als enige weet: de importpoort en waar afbeeldingsbytes vandaan komen. `TabsNotifier` staat daarmee 16 regels ónder zijn oude plafond; dat plafond is meeverlaagd. Dit is een hap uit #518. **Twee kleinere gaten uit dezelfde ronde.** `SyncEngine` leidt zijn `deletes` zelfstandig af en kwam langs de "niet aanraken"-regel heen: een onleesbaar notitiebestand plus een offline bewerking wiste alsnog beide kanten. Die ene uitzondering staat er nu, mét de reden dat dit het enige bestand in de deckmap is dat van iemand anders kan zijn. En `declaredSidecarVersion` valt bij alles wat geen map is terug op versie 1, dus een top-level array heette "verwijderbaar" — nu sinds FILE_FORMAT §6.3.1 uitnodigt dit bestand vanuit een ander werktuig te schrijven, is dat geen theorie meer. Twee native tests tegen een echte bare origin op schijf; beide worden rood tegen de onherstelde code. Plus drie in de sync-engine, met tegenproef. Ten slotte in GIT_STORAGE §9.7 opgeschreven wat correct is maar nergens stond: een notitie hoort bij de dia zoals die was, dus wie de dia van een ander herschrijft laat diens notitie erop los. Dat is de codecregel, niet iets wat deze merge verzint — maar in een gedeelde repo is het nu destructief, en dan hoort het opgeschreven. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>