4 ms·

> So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. This is the

> So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. This is the part that seems to sum that whole page up: > When pulling bug updates from a remote, we will simply add our new operations (that is, new Commits), if any, at the end of the chain. Which indicates it's just changing a value without any indication to you that you changed what someone else wrote. I'm not so arrogant as to claim that is what happens just from reading some text on a page, so I'd love for someone more experience with this tool to clarify how a "multiple edits of the same attribute" event flow plays out. > Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? They're just files in the repo, so conflicting changes behave exactly the same way changes in git or hg or whatever do: you have to resolve the conflict. > In fact, I think the very next paragraph in your link nicely illustrates how "decentralized" they are. This is what they say: > If you have any problems with BE, you can look for matching bugs: > $ be --repo http://bugs.bugseverywhere.org/ http://bugs.bugseverywhere.org/ list You know that this URL is? This is a primary BE bugs server. It is not using git, hg or any other decentralized protocol -- it is just good old centralized file storage. BE has the ability to query a remote bug repo without the need for cloning the entire git/hg/whatever-vcs/no-vcs repo it's hosted in. That's what you're seeing there. But hey good for you on a ridiculous rant based on misunderstanding something. Have a gold star. > Even their model -- storing bugs in the main branch ... bugs are stored in a directory, and versioned like regular files. 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. I don't know whether you just didn't read anything about BE, or you're deliberately making shit up to troll, but your claims are wildly inaccurate.

michaelmure 7y ago
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 7y 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 7y 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...

michaelmure 7y ago

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 7y 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 7y 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...