FughettaSemantic Granularity and Recovery Cost in Decentralized Version Control
· The Fughetta team
A short research letter based on a native sequence prototype and a signed Git reference
Abstract. Decentralized version control must preserve both source history and the identity of individual contributions. We compare a native sequence system with a Git reference under fixed editing and recovery workloads. Stable element identities allow the native system to reverse one contribution while preserving independent edits within the same line; the tested Git merge and inverse paths instead report explicit conflicts. This semantic advantage does not imply lower operational cost. The native system fails three time limits at 10,000 files and 10,000 edit batches. Git requires substantially less memory and storage, although its complete history audit and reconstruction also exceed the corresponding time targets. The results favor Git as the next implementation foundation while identifying contribution-aware reversal as a distinct capability that snapshot history alone does not supply.
Problem and model. A useful decentralized repository must answer two different questions: which source state should be visible, and which contribution produced it? Git records commits and trees; textual merging reconciles changes relative to a common ancestor [1]. Replicated data types can instead retain operation identities and causal relationships that determine how delivered updates compose [2]. These choices affect the information available for later editing, reversal, and recovery. Neither content hashes nor signatures determine the intended meaning of a source change.
We examine two concrete designs. The native prototype represents text as stable insertion runs with element identities, deletion claims, and explicit activation changes. File identity persists across moves. Signed batches bind the observed source, declared tool, intent, result, and effects. The Git reference stores source trees together with author-signed event records and accepting-node signatures on commits. Both bind retained evidence to actual source changes and verify original receipt issuers during reconstruction. Git can retain operation records, but storing those records does not by itself define an operation-aware inverse.
Convergence and selective reversal impose different conditions. Let H denote a validated causal history and P(H) its visible source projection. Convergence requires replicas with the same history and decisions to produce the same projection. For two concurrent contributions a and b made from the common history H, a selective reversal additionally seeks
P(R_a(H ∪ {a, b})) = P(H ∪ {b}) (1)
where R_a appends a reversal of a, retaining its historical evidence. Equation (1) applies when b has no dependency or unresolved conflict that blocks the reversal. It is a behavioral criterion for the evaluated cases, not a general theorem about arbitrary edits. Reversing a required source contribution must produce an explicit dependency decision rather than silently invalidating subsequent work.
Semantic experiment. Begin with abcd. Author A inserts AA after a; author B independently inserts BB after c. The native projection becomes aAAbcBBd. Reversing A yields abcBBd, and redoing A restores the combined text. Corresponding deletion and replacement cases also preserve B. The same-line Git reference reports an explicit merge conflict and an explicit conflict when applying the source inverse; a separate-line control composes and preserves B [3]. These results concern the tested textual merge path, not every possible Git merge driver. Git documents reversal as recording commits that reverse earlier changes [4]; preserving another contributor's edits at element granularity requires additional semantics.
The distinction extends beyond insertion. Independent deletion claims remain active when only one claim is reversed. Hidden insertion anchors can retain another author's descendants. Moves and mode changes can be reversed while preserving text contributed by another author. The prototype exposes overlapping replacements, competing activation choices, structural alternatives, and required dependencies as explicit conflicts. Deterministic text composition does not establish program correctness, and convergence does not settle authorization or policy.
Durability and trust. Both designs use immutable, addressed evidence and durable publication. Their shared integrity requirement is stronger than checking a signature: the signed effect must match the actual source change. A correctly signed false effect is rejected by the Git reference. The native receiver reconstructs effects from the signed request and observed source before accepting them. Native publication also binds author, operation identity, executor, and prior state, preventing a retry from becoming a second accepted effect. The Git reference audits operation uniqueness but does not implement the native retry protocol.
The native prototype separately models receipt, integration, and target admission. Receiving a valid remote branch leaves the selected local branch unchanged. A new node may recover an old receipt without becoming its issuer and may subsequently publish under its own identity. Its tested policy layer includes revocation settlement and explicit admission of previously unobserved work. The Git cost reference uses a linear publication history and static grants; it does not implement those production policy and peer contracts. The experiment therefore compares concrete implementation paths with different semantic scope, rather than equal-security substitutes differing only in storage format.
Measurement. Workload W1 imports 69 fixed source files and performs 1,000 edits distributed across three authors. Workload W2 imports 10,000 files of 4,096 bytes and performs 10,000 replacements in 100 repeatedly edited files. Both retain 1 KiB of intent and 4 KiB of result evidence per edit. A separate offline experiment forks after W1's first 500 edits, retains 100 additional edits on the disconnected node, and reconnects after the other node reaches 1,000 edits. Fixed inputs, raw results, and functional evidence are recorded in Ref. [3].
Measurements use the existing native Debug build with address and undefined-behavior sanitizers and installed Git 2.53.0. Complete opening verifies history and reconstructs the source. Full recovery includes export, import, validation, and materialization of working files. Peak memory covers complete process lifetimes; independent peers are measured separately. The Git estimate conservatively includes its Python coordinator and largest child. These configurations support a comparison of the evaluated implementations, not an intrinsic speed ranking of CRDTs and Git.
TABLE I. Final measurements. Opening reports the maximum of three trials. Memory reports the maximum across the measured final phases for each workload. MiB denotes 1,048,576 bytes. A dash marks a current-build write measurement that was not performed.
| Observable | Native W1 | Git W1 | Native W2 | Git W2 |
|---|---|---|---|---|
| Write p95 (ms) | 10.90 | 30.59 | — | 64.00 |
| Peak measured RSS (MiB) | 454.45 | 84.34 | 1,867.17 | 394.84 |
| Complete opening (s) | 2.557 | 0.808 | 47.878 | 41.544 |
| Full export and reconstruction (s) | 8.507 | 1.936 | 157.968 | 122.803 |
Native W1 satisfies its fixed limits, including a 5 s opening and a 15 s reconstruction budget. Its write p95 is lower than Git's, while its retained workload occupies 22.42 MiB versus 2.31 MiB for Git. The offline experiment reconnects in 5.511 s using 10,827,176 bytes. A third node reconstructs from the previously disconnected node, preserves its original receipt, and continues editing. These results demonstrate useful local semantics and recovery at the smaller scale.
W2 exposes a different regime. Native opening takes 47.33–47.88 s against a 30 s limit. Full export and reconstruction require 157.97 s against 120 s. A 1 KiB incremental source change, with the prescribed evidence, transfers only 18,501 bytes but takes 8.53 s against 5 s. The small message therefore does not imply low exchange latency. Profiling of the native opening path places most time in validation and source reconstruction, with a smaller contribution from object loading [3]. Asynchronous file operations alone cannot remove that measured CPU work.
The first complete native W2 producer achieved a 360.58 ms write p95 and occupied 330.75 MiB. Subsequent repairs changed loading and in-memory representations; those earlier write measurements are excluded from Table I's final-build comparison. Final read, exchange, recovery, and continuation measurements use the same generated history with the final binary. This preserves the workload while preventing historical costs from being relabeled as current performance.
Git's W2 workload occupies 32.60 MiB, but complete opening still requires 41.06–41.54 s, and full recovery requires 122.80 s. Both exceed the corresponding time targets. The lower memory and storage footprint is thus accompanied by a remaining cost of full history verification. Comparing byte counts or ordinary repository startup without that audit would answer a different question.
Interpretation. The observed tradeoff concerns semantic granularity and the cost of retaining, validating, and reconstructing it. Stable element identities make selective reversal directly expressible, but the evaluated native representation and replay path impose substantial resource costs. Git's compact retained history is attractive as a storage foundation, while its default textual merge semantics do not reproduce the tested contribution behavior. Neither representation alone provides policy, truthful execution receipts, or semantic correctness; those guarantees belong to the surrounding publication protocol.
The frozen selection rule requires every native gate to pass. The native system's W2 failures therefore reject it as the production kernel in this evaluation, despite its demonstrated same-line advantage. Git is selected as the foundation for the next production batches because of its lower measured resource costs and usable history primitives. That selection does not accept the reference as a finished product: its large-history audit and reconstruction still need work, and its policy, retry, and peer contracts remain to be implemented. The finite scenarios and measurements establish these implementation-level findings without proving asymptotic complexity, a universal crossover scale, or superiority for every collaborative workload.
The resulting design requirement is precise. Preserve the distinction between source history, individual contributions, and accepted execution evidence. When the representation cannot justify an automatic reversal, expose the conflict. When retained history can justify it, preserve independent work. A decentralized version-control system must make both behaviors explicit while meeting its recovery budget.
References
[1] Git Project, git-merge documentation, particularly “True Merge.”
[2] M. Shapiro, N. Preguiça, C. Baquero, and M. Zawirski, Conflict-free Replicated Data Types, Stabilization, Safety, and Security of Distributed Systems (2011).
[3] Fughetta, Native Sequence Prototype and Signed Git Reference, unpublished project evaluation (October 16, 2026). The workload definitions, measurements, and experimental limitations are summarized above; raw results are retained in the project evaluation record.
[4] Git Project, git-revert documentation.