13 ms·

Show HN: Git-bug – Distributed bug tracker, or what to do when GitHub is down

153 points by michaelmure 6y ago

smoyer 6y ago
I've been using this since I asked HN why BugsEverywhere failed (https://news.ycombinator.com/item?id=20963039 https://news.ycombinator.com/item?id=20963039) about six months ago and have to say it's far superior to BE. So far, I haven't found a case where the synchronization to Github didn't work as expected. I also have sensitive repositories that are hosted on Keybase and, since it doesn't include integrated bug tracking, we use Git-bug as a distributed team.
- eeZah7Ux 6y ago
  BugsEverywhere failed because github killed the distributed aspect of DVCS. The majority of github users do not understand the problem of lock-in. BugsEverywhere is much more lightweight and more mature than git-bug and does not encourage integration with closed-source forges.
  - michaelmure 6y ago
    What sort of maturity sign would you like to see?
  - theamk 6y ago
    I think BugsEverywhere might have failed because of suboptimal design and lack of features? I have not use BE nor git-bug before, but from looking at the doc pages, git-bug looks way superior. In particular, it looks that by default, BE stores bugs in main repo. Which probably means every comment is a commit, which puts lots of useless entries into the main commit log. (They do mention workflows that store bugs in separate branches.. but this seems undocumented, non-default option) Ironically, I am also not sure how well BE works in the distributed fashion. git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?)
    - stephenr 6y ago
      > BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project Literally the first paragraph of the first page about usage in the documentation (https://bugs-everywhere.readthedocs.io/en/latest/tutorial.html#introduction https://bugs-everywhere.readthedocs.io/en/latest/tutorial.ht... ) says exactly what you're talking about: > Bugs Everywhere (BE) is a bugtracker built on distributed revision control. The idea is to package the bug information with the source code, so that developers working on the code can make appropriate changes to the bug repository as they go. For example, by marking a bug as “fixed” and applying the fixing changes in the same commit. This makes it easy to see what’s been going on in a particular branch and helps keep the bug repository in sync with the code.
      - theamk 6y ago
        You have snipped the first part of my message. This is what I said: > git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?) So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? The manual certainly does not tell. When I looked at the bugtracker for BE itself, looks like they don't have any special handling of this, and concurrent PRs will conflict. And for comments, we just use timestamps and don't try to have consistent ordering in any way ( 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. Even their model -- storing bugs in the main branch -- prevents decentralization, as ability to file bugs (usually granted to everyone) requires ability to commit to master (usually restricted). So yes, they claim things on the page, but they don't expect true decentralized operation, just a one way mirror. [0] https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [1] https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/301724b1-3853-4aff-8f23-44373df7cf1c/values https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4...
gbrown_ 6y ago
The title is somewhat editorialized with the "or what to do when GitHub is down". A previous discussion of git-bug https://news.ycombinator.com/item?id=17782121 https://news.ycombinator.com/item?id=17782121
capableweb 6y ago
Related: Fossil SCM is a distributed source code manager (just like Git), but with the added benefit that documentation and issues also goes in the repository (so like GitHub, but packed into the repository). When you clone a Fossil repository, you get everything, not just the code. http://fossil-scm.org/ http://fossil-scm.org/ Also been discussed on HN before, a selection: - Fossil VS Git (https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...) - https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 - https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=12673229 I haven't personally used it for more than toy projects, but looks very interesting and would love to use it more.
- rkeene2 6y ago
  Not just the Wiki and Issues, but also more things like release artifacts can be (optionally) sync'd and are part of the repository (as "unversioned content"). There's also a Forum included, and as with the rest those messages are distributed.
- theamk 6y ago
  Just don't forget that Fossil does not support rebase/amend, on principle. So if you want both "commit very often" and "have nice, readable commits with clear descriptions", it is not for you.
  - thunderbong 6y ago
    You can't change history. In a version control system, this is axiom 0.
    - jdbernard 6y ago
      You can. That is certainly a possible axiom as evidenced by fossil and some others, but as evidenced by git and common usage it is not necessarily "axiom 0" for all possible VCS's. Unless you want to get really semantic in which case, sure "history" can't be changed, but "recorded history" certainly can.
kbr2000 6y ago
I'm using Fossil for this: https://fossil-scm.org/ https://fossil-scm.org/ Written by the SQLite author (and based on SQLite).
rapnie 6y ago
Also see: https://news.ycombinator.com/item?id=17782121 https://news.ycombinator.com/item?id=17782121 (2018)
ithkuil 6y ago
Reminds me of ticgit https://github.com/jeffWelling/ticgit https://github.com/jeffWelling/ticgit
- JNRowe 6y ago
  And perhaps ditz¹ [+ pyditz²], BugsEverywhere³, git-issue⁴. As someone who -- I guess obviously -- cares about distributed issue tracking, I really like the direction and implementation of git-bug. The termui subcommand is really cool, and it appears to be enough to push co-workers to try it when they normally push back on "weird" tools. I think the closest we had to user friendly before was the read-only web interfaces in ditz and BE, but user friendly isn't all that friendly if it is read-only. 1. https://rubygems.org/gems/ditz https://rubygems.org/gems/ditz 2. https://pypi.org/project/pyditz https://pypi.org/project/pyditz 3. http://www.bugseverywhere.org/ http://www.bugseverywhere.org/ 4. https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue
  - bmn__ 6y ago
    Also see: Simple Defects https://syncwith.us/sd/ https://syncwith.us/sd/ https://github.com/bestpractical/sd https://github.com/bestpractical/sd https://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-replicated-disconnected-database#24 https://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-...
  - kwk1 6y ago
    There's also Radicle: https://radicle.xyz/ https://radicle.xyz/
IshKebab 6y ago
Can you attach images and videos to bugs?
- michaelmure 6y ago
  Not yet but it's in the works.
Proven 6y ago
The inconvenience of using a distributed bug tracker all year round must be much worse than taking a small break when Github is down.
carlsborg 6y ago
Awesome work Michael. This is the logical way forward for decentralised apps.
- michaelmure 6y ago
  Thank you :)
toyg 6y ago
Git is becoming the new emacs. I wonder when git email read will appear... Joking aside, I’m very tempted to use this thing for my current side-project.

153 points by michaelmure 6y ago

I've been using this since I asked HN why BugsEverywhere failed (https://news.ycombinator.com/item?id=20963039 https://news.ycombinator.com/item?id=20963039) about six months ago and have to say it's far superior to BE. So far, I haven't found a case where the synchronization to Github didn't work as expected. I also have sensitive repositories that are hosted on Keybase and, since it doesn't include integrated bug tracking, we use Git-bug as a distributed team.

eeZah7Ux 6y ago
BugsEverywhere failed because github killed the distributed aspect of DVCS. The majority of github users do not understand the problem of lock-in. BugsEverywhere is much more lightweight and more mature than git-bug and does not encourage integration with closed-source forges.
- michaelmure 6y ago
  What sort of maturity sign would you like to see?
- theamk 6y ago
  I think BugsEverywhere might have failed because of suboptimal design and lack of features? I have not use BE nor git-bug before, but from looking at the doc pages, git-bug looks way superior. In particular, it looks that by default, BE stores bugs in main repo. Which probably means every comment is a commit, which puts lots of useless entries into the main commit log. (They do mention workflows that store bugs in separate branches.. but this seems undocumented, non-default option) Ironically, I am also not sure how well BE works in the distributed fashion. git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?)
  - stephenr 6y ago
    > BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project Literally the first paragraph of the first page about usage in the documentation (https://bugs-everywhere.readthedocs.io/en/latest/tutorial.html#introduction https://bugs-everywhere.readthedocs.io/en/latest/tutorial.ht... ) says exactly what you're talking about: > Bugs Everywhere (BE) is a bugtracker built on distributed revision control. The idea is to package the bug information with the source code, so that developers working on the code can make appropriate changes to the bug repository as they go. For example, by marking a bug as “fixed” and applying the fixing changes in the same commit. This makes it easy to see what’s been going on in a particular branch and helps keep the bug repository in sync with the code.
    - theamk 6y ago
      You have snipped the first part of my message. This is what I said: > git-bug has this nice section on how they implemented CRDTs using git, so everyone can comment at once at there are no conflicts. BE, on the other hand, seem to have no mention of such thing? In fact, I think they assume single central bug repository per project, on some server which handles email submission (how else can one implement debian bugtracker-style email interface?) So, here is git-bug talking about multiple submissions: [0]. It talks about how to order messages and resolve conflicts in decentralized fashion. Does BE has anything like this? What happens if two people try to claim a bug or change severity to different values? The manual certainly does not tell. When I looked at the bugtracker for BE itself, looks like they don't have any special handling of this, and concurrent PRs will conflict. And for comments, we just use timestamps and don't try to have consistent ordering in any way ( 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. Even their model -- storing bugs in the main branch -- prevents decentralization, as ability to file bugs (usually granted to everyone) requires ability to commit to master (usually restricted). So yes, they claim things on the page, but they don't expect true decentralized operation, just a one way mirror. [0] https://github.com/MichaelMure/git-bug/blob/master/doc/model.md https://github.com/MichaelMure/git-bug/blob/master/doc/model... [1] https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/301724b1-3853-4aff-8f23-44373df7cf1c/values https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4...

gbrown_ 6y ago

The title is somewhat editorialized with the "or what to do when GitHub is down". A previous discussion of git-bug https://news.ycombinator.com/item?id=17782121 https://news.ycombinator.com/item?id=17782121

capableweb 6y ago

Related: Fossil SCM is a distributed source code manager (just like Git), but with the added benefit that documentation and issues also goes in the repository (so like GitHub, but packed into the repository). When you clone a Fossil repository, you get everything, not just the code. http://fossil-scm.org/ http://fossil-scm.org/ Also been discussed on HN before, a selection: - Fossil VS Git (https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...) - https://news.ycombinator.com/item?id=19006036 https://news.ycombinator.com/item?id=19006036 - https://news.ycombinator.com/item?id=12673229 https://news.ycombinator.com/item?id=12673229 I haven't personally used it for more than toy projects, but looks very interesting and would love to use it more.

rkeene2 6y ago
Not just the Wiki and Issues, but also more things like release artifacts can be (optionally) sync'd and are part of the repository (as "unversioned content"). There's also a Forum included, and as with the rest those messages are distributed.
theamk 6y ago
Just don't forget that Fossil does not support rebase/amend, on principle. So if you want both "commit very often" and "have nice, readable commits with clear descriptions", it is not for you.
- thunderbong 6y ago
  You can't change history. In a version control system, this is axiom 0.
  - jdbernard 6y ago
    You can. That is certainly a possible axiom as evidenced by fossil and some others, but as evidenced by git and common usage it is not necessarily "axiom 0" for all possible VCS's. Unless you want to get really semantic in which case, sure "history" can't be changed, but "recorded history" certainly can.

kbr2000 6y ago

I'm using Fossil for this: https://fossil-scm.org/ https://fossil-scm.org/ Written by the SQLite author (and based on SQLite).

rapnie 6y ago

Also see: https://news.ycombinator.com/item?id=17782121 https://news.ycombinator.com/item?id=17782121 (2018)

ithkuil 6y ago

Reminds me of ticgit https://github.com/jeffWelling/ticgit https://github.com/jeffWelling/ticgit

JNRowe 6y ago
And perhaps ditz¹ [+ pyditz²], BugsEverywhere³, git-issue⁴. As someone who -- I guess obviously -- cares about distributed issue tracking, I really like the direction and implementation of git-bug. The termui subcommand is really cool, and it appears to be enough to push co-workers to try it when they normally push back on "weird" tools. I think the closest we had to user friendly before was the read-only web interfaces in ditz and BE, but user friendly isn't all that friendly if it is read-only. 1. https://rubygems.org/gems/ditz https://rubygems.org/gems/ditz 2. https://pypi.org/project/pyditz https://pypi.org/project/pyditz 3. http://www.bugseverywhere.org/ http://www.bugseverywhere.org/ 4. https://github.com/dspinellis/git-issue https://github.com/dspinellis/git-issue
- bmn__ 6y ago
  Also see: Simple Defects https://syncwith.us/sd/ https://syncwith.us/sd/ https://github.com/bestpractical/sd https://github.com/bestpractical/sd https://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-replicated-disconnected-database#24 https://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-...
- kwk1 6y ago
  There's also Radicle: https://radicle.xyz/ https://radicle.xyz/

IshKebab 6y ago

Can you attach images and videos to bugs?

michaelmure 6y ago
Not yet but it's in the works.

Proven 6y ago

The inconvenience of using a distributed bug tracker all year round must be much worse than taking a small break when Github is down.

carlsborg 6y ago

Awesome work Michael. This is the logical way forward for decentralised apps.

michaelmure 6y ago
Thank you :)

toyg 6y ago

Git is becoming the new emacs. I wonder when git email read will appear... Joking aside, I’m very tempted to use this thing for my current side-project.