Show HN: git-bug – Distributed bug tracker embedded in git
github.com
github.com
- You should post this to the Git mailing list. We don't bite, and a lot of people would be interested in the details of how it works there.
- If you haven't you should check out git-annex. It solves an entirely different problem, but much of the distributed custom merging of histories, using git for ad-hoc metadata etc. is the same problem you're solving.
- You should be aware if you aren't that the design of having a ref per bug has some drawbacks, some operations in git are O(n) the number of refs.
- It would be really interesting to see some write-up on how the format you're using compares to the format Fossil uses for its bugs. I think some of what Fossil does wouldn't be possible to do in git due to its simpler data model, but still, such a comparison would be educational.
A bug tracker like this allows the bug history to be tracked and remain with the source code which is much better than keeping the bugs in a web based service because every 5 years you need to migrate it (Bugzilla to Trac to JIRA) and in every migration, some context or formatting is lost.
For something like this to be successful in enterprises, the tool should be management-friendly. Right now JIRA leads because it allows management to pull pretty reports out of it. Is there anything planned in git-bug to appease these management type people so that it has a good chance of taking off in the enterprise world too?
Also, the design of Fossil and Chisel is s bit difficult to read on mobile.
Edit: corrected SQLite URL.
Fossil's neat because it really tries hard to be decentralized. Because of that the repo is really all you need. Hosting isn't so important when code, bugs, forums, and wiki can be moved by copying one file. The downside is that there's no FossilHub with thousands of projects using similar UIs and conventions.
As far as Fossil hosts go, I know of at least one more: https://secure.hydra.ecd.space/
That's just the default. You can easily change the CSS, though it would be nice if you could select from themes created by others, particularly to get one that's friendlier for mobile users.
Now we just need to be able to also put a wiki in the same repo.
mkdir Notes/
vim Notes/index.wiki
git add Notes/index.wiki
Since it's just tracked as a normal part of the repo, it gets branched and merged along with the code. So for example if I make an experiments branch, any wiki changes regarding the experiment won't sit around polluting the wiki if I decide to drop the branch. Similarly, any changes relevant to the branch I am working on get merged together along with the code merge.
One of the more interesting projects now a days is ForgeFed (https://github.com/forgefed/forgefed) which would allow for projects to use ActivityPub for pull requests, forking, etc.
This is important because so much of the value add of Github isn't in the git hosting (which one can do with Gitea or Gitlab) but in the collaboration.
This is also important because many Github extensions work through their API to glue functionality such as test suites and linting through monitoring a PR.
So where might your project fit in there?
The argument that connectivity is an impediment is valid, but increasingly less so.
The problem with storing bugs in git is that you are forcing the users to download the entire project, or to make a PR for each comment, etc.
So a bridge would make things much easier.
This is clearly more elegant, though it adds a new dependency, which is OK.
I really like that, too, I wish we'd track our requirements in git instead of having an IBM enterprise solution which is slow, has a terrible web interface and no ability to diff requirements properly.
The more information is versioned in the same system, the better the coherence of the information.
So does that mean that bug reports are tied to branches? (I.e. depending on which branch you've checked out, you see a different list of bugs?) I wouldn't like that idea at all because how would you keep track of bugs (and related discussions) across branches? (For instance, having 10 branches would imply that you suddenly have 10 versions of the same bug discussion, too.)
I see more value in it for clear technical tasks with technical descriptions, and not so much for discussions. Then proposals can be peer-reviewed before accepted as work that needs to be done (as a merge request to master, for example).
Then another problem that comes along with that, especially for golang users, is that your master branch is getting bombarded with issue updates, causing what looks like releases, when there's no effective change.
Maybe someday git projects will have a /tickets folder or branch? Tickets per branch... hmmm... Maybe ignore the ones not in Master
BugsEverywhere was broken last time I tried it (one of its git submodules wasn't resolvable IIRC)
Given that, I am looking for an extremely niche but vital feature: the ability to keep track of which branches a bug has been fixed in. Is this something git-bug can or does enable?
Please open an issue so we can discuss that.
I imagine the most difficult part of this is just getting the data collected. Even with git-bisect, I very rarely find myself looking for the point of introduction, and instead just fixing the bug.
It uses a dedicated "bugs" branch checked out to a .bugs directory in the current working directory. To use, copy it to a git repository which has a master branch and a remote for this master branch an run it.
Very bare-bones, but so far sufficient and without external dependencies (but probably lots of security problems…).
The one thing that I'm not sure about is the separate `git bug push/pull` commands. I guess it makes sense, but I'd prefer ordinary `git pull/push/fetch/merge` to seamlessly handle syncing bugs around.
git push/pull doesn't touch references outside of branches and git-bug has special code in the push/pull commands to merge bugs when needed.
How does that work with garbage collection?
As each bug reference the file blob needed, once your delete a bug, `git gc` will clean these blob as well.
The question isn't whether the data will be garbage collected, but how the active data AVOIDS being garbage collected - git gc only targets a pretty small amount of refs to preserve.
I'd be fine running a patched git that knows about bugs. Of course, then I'd want to make it a little more generic, and not care whether I was dealing with an issue tracker, a wiki, etc.
Full disclosure: I work for GitLab, but what I stated above has nothing to do with the fact, it's how I personally see GitLab as a product.
That's what I meant by "integrated services already possible with Github". I guess you are familiar with Github Marketplace.
I don't mean to offend GitLab, it's a great service, I just mean that it could be much more if it worked on low level things too, like storage of issues as git objects, or federated instances. These are hard problems that won't make GitLab easy sell to a manager but definitely interesting things that would get developers attention.
A really interesting low-level component that we created and use in production is gitaly [4] (which is a git RPC component that aims to completely remove GitLab's dependency on NFS for repository access - and replace it with gitaly itself).
[1] - https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
[2] - https://gitlab.com/gitlab-org/gitlab-ee/issues/4517
https://gitlab.com/gitlab-org/gitlab-ce/issues/23029
which is requested by Drupal (among others):
https://www.drupal.org/drupalorg/blog/developer-tools-initia...
http://bugseverywhere.org/ has been around for a long time but services like GitHub and GitLab refuse to support its format, effectively blocking the adoption of the tool.
As far as I understand, the data model of git-bug is much closer than what github does internally. If you look at githug's API, you will find the same timeline of edit operation, so it might help them to pick up the idea.
The population you desire to be able to update tickets is... shall we say, "larger" ? ;) than the population you desire to be able to update code.
For any project where the bug-updaters and the code-updaters are plausibly the same set, this could be a useful thing.
But even for modest projects I'm doing for customers, it'd be awkward.
I also think the type of data your bug-updaters or bug-reporters would generate would be very different. Do you really want 23 gargantuan screenshots as blobs retained in perpetuity?
My kneejerk is that the bug metadata is a different _kind_ of data than the source, and trying to shoehorn them into the same container will be stuffy in most cases.
A really good point. I'd say you should use something like this for internal bug tracking, and link to external bug reports instead.
Whether you accept an external bug report as an actual bug is a question in itself, which should be dealt with beforehand. I'd say this is good for notetaking for the team and for seeing which bugs are resolved in which version.
Yes! It's much better than having them linked from some image hoster that inevitably goes belly-up at some point.
The problem of not necessarily wanting to pull them after they've been lying around for 10 years can also be solved, see git-lfs.
I don't see your point about the permission model.
You will have access permission for the code as you normally do for your git remote as well as an extra user for the web UI that will store bug edits as one of the "public" user with whatever external authentication system you want.
There's a whole bunch of ways to handle large files in git nowadays without bloating the size of the repo. Hopefully the distributed bug tracker would work with those...
That said, as a developer I'd love it if I could track my more technical thoughts & needs without having to go to my enterprise tools where BA's run wild & confused. The trade-off of course being more dissonance and potentially a failure to advocate for this work in planning, unless you synchronize data somehow.
The most successful company I worked for used two systems. There was an "external" user-friendly one, where customers could file issues and track changes and tie them back to contractual requirements and such, and there was an "internal" developer-friendly one, where programmers could talk about what line of the source code forgot to add one and which changeset hash introduced the bug.
Our partners wanted to file issues at the level of "I need to have some way to be able to do XYZ", and they shouldn't have visibility into source code and programmer assignments and internal roadmaps. Our programmers broke these into "Write a function to do X()" and "Add a database table for Y" and "Z.c crashes when you leave the title field blank", and they shouldn't be exposed to customer data that was part of the request.
It worked tremendously well, and I'm surprised this split approach isn't more popular. git-bug looks like it could be a great solution for the internal one.
[1] https://en.wikipedia.org/wiki/IBM_Configuration_Management_V...
Maybe it could work to develop a core protocol and data structures that are usable by others, with your own go implementation to work with those structures and protocol.
A tool like this would have reduced the productivity hit during those periods.
[1] https://sit.fyi
Reading over this page https://github.com/MichaelMure/git-bug/blob/master/doc/model... gives me the impression that you’re reproducing some of Git’s functionality. Can you elaborate on why Git’s merge model is insufficient and why the “Operation/OperationPack” serves the distributed-edits problem better than Git itself? Or alternatively, explain what I’m missing about how this doesn’t step on Git’s toes? Congrats on building this and shipping it!
Apart from that, a normal git rebase would merge two versions of the same bug conflict free. Each commit is independent from the other. A merge is simply moving the new operations at the end of the chain of edit.
If for instance, that means that you closed a bug that is already closed, well the bug is still closed and your action will still be displayed in the timeline.
[0]: https://github.com/MichaelMure/git-bug/blob/c974cc022d3ecd2e...