
Show HN: Git-bug – Distributed bug tracker, or what to do when GitHub is down - michaelmure
https://github.com/MichaelMure/git-bug
======
capableweb
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.wik...](https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki)) -
[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.

~~~
theamk
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
You can't change history.

In a version control system, this is axiom 0.

~~~
theamk
Well, I need _something_ where I store temporary files. Like right now, I am
in the middle of prototyping major new functionality. It is huge, it is ugly
(still) and it touches a half dozen of major subsystem.

It is a huge blob of changes. When it will be ready, I'd have to split it to
maybe 6 to 8 commits, with well written commit messages. But I cannot do this
yet -- for all that I know, I'll find out my design was bad, and I'll have to
change those things tomorrow.

So the question is: what do I do with it?

In the old days, I had a VCS which could not change history (SVN). So I'd keep
multiple worktrees and back them up manually ("project-2009-12-03.tar.gz",
"file1.cc.before-refactor") and so on. The data would be lost sometimes. It
was a pain generally.

Now, I have a git branch. It has commit messages like "fix crash in Foo()",
"what if we used trie?", "oops forgot to update Bar to match" and so on. They
should never see the light of day, and they won't -- they'll get re-made into
different commits later. And git will help me to make sure the changes are not
lost.

It looks like with the fossil, I should be going back to multiple worktrees
and manual backups. I don't understand why would one want to do so.

~~~
rkeene2
With Fossil you could create many private branches off your feature branch
with your experiments, and merge them into your feature branch when you're
satisfied with that experiment.

~~~
theamk
that's the thing -- I'll be making 6-8 different branches out of that
experimental branch.

In rebase world, I have a cycle of "cherry-pick a few changes, get them into
master, rebase experimental so it gets smaller; repeat until nothing is left
of experimental"

In permanent world, I guess I have two worktrees and copy files one-by-one,
manually?

~~~
hinkley
Seems like you should be able to write a 'rebase' tool that just does a
sequential cherry-pick...

~~~
theamk
That's git's rebase with --onto and --interactive flags, I already use it and
it is great.

The question is, why would people give this up and move to Fossil?

~~~
josephg
Why can't we have both?

It seems like both "an immutable view of what happened" and "a crafted
narrative of feature changes, bug fixes and releases" are useful. Its
ridiculous that I'm expected to pick one. Git and fossil should raise their
game.

(Yes; git's tooling supports _either_ approach, but not both at the same time.
A better tool would let me avoid making this tradeoff at all.)

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

~~~
theamk
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
> 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.ht...](https://bugs-
everywhere.readthedocs.io/en/latest/tutorial.html#introduction) ) 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
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...](https://github.com/MichaelMure/git-
bug/blob/master/doc/model.md) [1]
[https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4...](https://github.com/kalkin/be/blob/master/.be/bea86499-824e-4e77-b085-2d581fa9ccab/bugs/301724b1-3853-4aff-8f23-44373df7cf1c/values)

~~~
stephenr
> 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
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_re...](https://github.com/matrix-org/matrix-
doc/blob/erikj/state_res_msc/proposals/1442-state-resolution.md) [3]:
[https://github.com/MichaelMure/git-
bug/issues/16#issuecommen...](https://github.com/MichaelMure/git-
bug/issues/16#issuecomment-415225166)

~~~
stephenr
> 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
"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/repositor...](https://github.com/MichaelMure/git-
bug/blob/master/repository/repo.go)

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

------
gbrown_
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)

------
ithkuil
Reminds me of ticgit
[https://github.com/jeffWelling/ticgit](https://github.com/jeffWelling/ticgit)

~~~
JNRowe
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__
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-...](https://www.slideshare.net/obrajesse/prophet-a-peer-to-peer-
replicated-disconnected-database#24)

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

~~~
michaelmure
Thank you :)

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

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

------
IshKebab
Can you attach images and videos to bugs?

~~~
michaelmure
Not yet but it's in the works.

