Branching & merging (Git-style)

[gsvarovsky]

m-ld's protocol maps to Git's, with (roughly):

• 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 Constraint insert assertions may have unexpected effects #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 Data recovery on fork #30). This could be out-of-scope but investigation might be enlightening.