git-bug's reusable entity data model
====================================
This document explains how git-bug's reusable distributed data structure in git is working. This data structure is capable of:
- storing an entity (bug, pull-request, config...) and its complete history in git
- carry signed authorship of editions
- use git remotes as a medium for synchronisation and collaboration
- merge conflicts
- respect the rules you define as to what edition are possible
- carry attached media
If you are looking for a different writing format or to see how you can easily make your own, checkout [the example code](../entity/dag/example_test.go).
If you are not familiar with [git internals](https://git-scm.com/book/en/v2/Git-Internals-Git-Objects), you might first want to read about them, as the `git-bug` data model is built on top of them.
## Entities (bug, author, ...) are a series of edit operations
As entities are stored and edited in multiple processes at the same time, it's not possible to store the current state like it would be done in a normal application. If two processes change the same entity and later try to merge the states, we wouldn't know which change takes precedence or how to merge those states.
To deal with this problem, you need a way to merge these changes in a meaningful way. Instead of storing the final bug data directly, we store a series of edit `Operation`s. This is a common idea, notably with [Operation-based CRDTs](https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type#Operation-based_CRDTs).
This file has been truncated. show original
