Instead of storing bug state, git-bug store intent of the users in a chain of commit. When read, those intents are interpreted and compiled into the state of the bug at that point. When a concurrent edition happen and a merge is needed, the concurrent operations are reordered as well as possible and a new state is computed. This state might not be the perfect state but: - it is guaranteed that the bug is in a legal state (no actual merge conflict making the data unreadable) - even if the reorder is not the one you would have wanted, the intent of user is preserved. It is clear who did what and you can "fix" the state manually by adding more operations if needed.
I'm not 100% sure that it's the optimal solution but it works. It might break in some full P2P scenario. To be honest, I'd like to eventually move over a full DAG of operation instead of this purely linear way so the conflicts can be merged in a more optimal way. See [1] and [2] for details.
What I'm sure though is that storing the state directly in git and especially alongside the code is the bad way to do it. It does lead to have unreadable state and badly merged state, and has been stated as a reason for failure by at least one similar project.
> The entire point being that as you make a change to the code in a branch, when finished you can also close the bug in that branch. When merged, that bug is now closed.
It's a nice feature but implementing that way implies the shortcoming described above. I believe the best way to implement that is to have git-bug "aware" of branches and have it react to those changes to either change the state or recompute it on the fly so the conflict resolution characteristics can be preserved. See [3].
[1]: https://github.com/MichaelMure/git-bug/issues/212 [2]: https://github.com/matrix-org/matrix-doc/blob/erikj/state_re... [3]: https://github.com/MichaelMure/git-bug/issues/16#issuecommen...