4 ms·

I won't comment on BE because I simply don't know enough about it but I'll try to clarify some things. Instead of storing bug state, git-bug store intent of t

I won't comment on BE because I simply don't know enough about it but I'll try to clarify some things. 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 https://github.com/MichaelMure/git-bug/issues/212 [2]: https://github.com/matrix-org/matrix-doc/blob/erikj/state_res_msc/proposals/1442-state-resolution.md https://github.com/matrix-org/matrix-doc/blob/erikj/state_re... [3]: https://github.com/MichaelMure/git-bug/issues/16#issuecomment-415225166 https://github.com/MichaelMure/git-bug/issues/16#issuecommen...

stephenr 6y ago
> 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. Everyone has different priorities. I'd argue that tying your tool specifically to git is a worse problem than dealing with merges.
- michaelmure 6y ago
  "git" is in the name but it's actually not tied to it so much. If you can implement those interfaces [1], you can port it to another VCS and everything else will work. It's not trivial but entirely possible. [1]: https://github.com/MichaelMure/git-bug/blob/master/repository/repo.go https://github.com/MichaelMure/git-bug/blob/master/repositor...

stephenr 6y ago

> 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. Everyone has different priorities. I'd argue that tying your tool specifically to git is a worse problem than dealing with merges.

michaelmure 6y ago
"git" is in the name but it's actually not tied to it so much. If you can implement those interfaces [1], you can port it to another VCS and everything else will work. It's not trivial but entirely possible. [1]: https://github.com/MichaelMure/git-bug/blob/master/repository/repo.go https://github.com/MichaelMure/git-bug/blob/master/repositor...