713 karma · joined January 24, 2018
The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.
- git-bug use a form of logical clock (not wall clock) that order an action in relation to other actions in the repo. Clock drifting doesn't matter.
- pushing to git usually require some access to the repo, and therefore abuse can be dealt with socially (aka you get kicked out)
What can happen for example is someone write a comment, shut down the computer and only push the next day, but in that case the comment showing up before yours is the correct merging.
See also https://github.com/git-bug/git-bug/blob/master/doc/design/da... and https://github.com/git-bug/git-bug/blob/master/entity/dag/ex...
I'd love to see this used in the wild for other use cases.
With golang, you can run fuzzing as simply as you run tests, which means that it's trivial to target specific parts of your application or library. It obsoletes so much of those techniques.
I'm quite curious of techniques to guide more the fuzzing. It seems like the best you can do is provide a seed corpus and hope for the best.
I originally wrote something akin to an op-based CRDT and enforcing a purely linear series of commits in git's DAG, but eventually found that it doesn't really work in a multiplayer configuration. Eventually, I realized that I could instead have a real DAG to capture the concurrent editions, with "empty commits" as DAG merge operation.
The result is more or less what is described in that article, with some nice properties:
- written in go, I now have a generic implementation[3][4] that, given a set of operation, can easily support many practical use cases (bug tracker issue is the first, kanban and pull-requests coming).
- git itself is taking care of the storage and the synchronization with peers (aka git remotes). I get the full set of upsides described in the article.
- unfinished for now, but I can leverage some git construct to crypto sign each interaction with the data structure, to prove authenticity and later construct a proper access right system (who can edit a comment, who has admin right ...).
- additionally to the DAG structure, I also have lamport clock to give an order between each independent DAGs (last edited bug ...). They are also used as a help to compute the final order within a DAG if there is ambiguity (concurrent editing).
I'm much more an engineer than a researcher, so it'd be awesome to have the opinion of the community and especially iamwil, hecturchi or lxpz.
[1]: https://github.com/MichaelMure/git-bug [2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model... [3]: https://github.com/MichaelMure/git-bug/blob/master/entity/da... [4]: https://github.com/MichaelMure/git-bug/tree/master/entity/da...
There is people arguing both ways with relatively good arguments, but what about quantifiable realities? As the author of GPL-licensed softwares, I didn't have much reasons to go that way or another, apart from hunch. Can we quantify those effects, so that we can properly align our licenses with the effect we want?
- CRDT-like reusable data structure [2][3] for true p2p workflow and easily create new entities (code review ...)
- bidirectional bridges to github, gitlab ... to ease the transition or just use git-bug as a complement of those platform
- CLI, terminal UI and web UI, for different taste and integrate into your tooling/workflow
[1]: https://github.com/MichaelMure/git-bug
[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model...
[3]: https://github.com/MichaelMure/git-bug/blob/master/entity/da...
Offline-first bug tracker (and soon-ish forge) embedded in git.
I keep working on this because the idea makes a lot of sense to me, because I learn a lot from it and it benefits me indirectly.
I'm not especially looking to monetize, but I'm curious about what this community think about it.
I'm considering adding a dedicated CLI command for that as it's a common concern.
- support for pull-requests
- support for external auth in the webUI, to make it work as a public frontend where anyone can browse and interact with bugs like any other forge
If that happens and people are convinced, I'd think that git-bug would become a natural companion for git. Then it's just a matter of packaging.