Every m-ld.transaction is a git.commit on the local clone (same word!)
Every commit is pushed to all remotes' main asap
Every commit on a remote's main is merged into local asap
Merges never conflict, and are immediately committed
This is driven by m-ld's realtime principle. However, there will certainly be times when a more measured Git style would be an advantage:
The longer a clone is offline, the more chance there is for operations to break some semantic rule that is intuitive to the consumers but unknown to m-ld, and for the 'merge' to therefore generate nonsense, or lose someone's intentions (the general case of #55). This could be mitigated by an explicit separation of merge-commit, with the opportunity to eyeball the result of the merge before the commit.
Some use-cases may want to explicitly have multiple collaborators working on a 'branch', before 'merging' into the 'main' (see also #30). This could be out-of-scope but investigation might be enlightening.
m-ld's protocol maps to Git's, with (roughly):
This is driven by m-ld's realtime principle. However, there will certainly be times when a more measured Git style would be an advantage: