aaiyer

bugseverywhere

Python2018–2026

aaiyer / bugseverywhere

bugseverywhere

Bugs Everywhere (BE), a bugtracker built on distributed version control.

Systems & Infrastructure Developer Tools

Explore on GitHub Read Hacker News discussions

3Distinct people

6Mentions

0Explicit recommenders

18GitHub stars

REPOSITORY AT A GLANCE

What to know before exploring

What it is

Bugs Everywhere (BE), a bugtracker built on distributed version control.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

dspinellis/git-issue · linked in 2 of the same discussions
git-dit/git-dit · linked in 2 of the same discussions
google/git-appraise · linked in 2 of the same discussions

Mentioned in the same Hacker News threads. That is not proof they are substitutes.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year6 dated mentions

Observed mentions: 2018-06-04 01:47:25 UTC to 2026-05-01 11:04:28 UTC.

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges

UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
Period	Start (UTC)	End (exclusive, UTC)	Mentions	Comments
2018	2018-01-01 00:00:00 UTC	2019-01-01 00:00:00 UTC	1	1
2019	2019-01-01 00:00:00 UTC	2020-01-01 00:00:00 UTC	0	0
2020	2020-01-01 00:00:00 UTC	2021-01-01 00:00:00 UTC	1	1
2021	2021-01-01 00:00:00 UTC	2022-01-01 00:00:00 UTC	1	1
2022	2022-01-01 00:00:00 UTC	2023-01-01 00:00:00 UTC	0	0
2023	2023-01-01 00:00:00 UTC	2024-01-01 00:00:00 UTC	0	0
2024	2024-01-01 00:00:00 UTC	2025-01-01 00:00:00 UTC	1	1
2025	2025-01-01 00:00:00 UTC	2026-01-01 00:00:00 UTC	1	1
2026 (partial)	2026-01-01 00:00:00 UTC	2027-01-01 00:00:00 UTC	1	1

What Hacker News says

6 sources

mananaysiempre·May 1, 2026

There were a few efforts like that back in the day (when people still cared about offline and store-and-forward-style operation[1]), like Bugs Everywhere[3], git-appraise[4] which stored its data in Git’s little-known “notes” namespace[5], and git-bug[6] which for some reason I’ve seen mentioned quite a bit in such threads recently unlike the others—though I’m not complaining about one of them getting mentioned at least. Also, as far as read-only access, Gerrit review data is actually accessible via Git[7] (for review ABCDE, pull refs/changes/DE/ABCDE/meta instead of one of the usual numbered refs under that prefix), and someone made the effort[8] to make it accessible via Git notes too (as mentioned in the post on Git notes that I linked above). Also also, the Fossil SCM of SQLite fame somewhat famously does[9] do this kind of thing with

Read the rest

its builtin bug tracker. It has been relegated to obscurity partly as an accident of history (Git won) and partly on the merits (it is aggressively hostile to the kind of history rewriting we are used to routinely—if not always wisely—performing in Git). Going back to working on top of Git, though, I think that part of the problem is that you really want custom merge strategies when you’re trying to build a fancy datatype, and Git’s support for them requires a lot of wrapping to make it seamless (the location tracking stuff in git-annex[10] is the only success story I am aware of, and that’s a sizeable Haskell project). The existing porcelain is just too rigid. [1] Can I have a viable replacement for PGP for that use case? Please stop telling me that I don’t exist and should screw off[2]? Please?.. [2] https://news.ycombinator.com/item?id=44239804 [3] https://github.com/aaiyer/bugseverywhere [4] https://github.com/google/git-appraise [5] https://tylercipriani.com/blog/2022/11/19/git-notes-gits-coo..., https://news.ycombinator.com/item?id=44345334 (579 points, 146 comments) [6] https://github.com/git-bug/git-bug [7] https://gerrit-review.googlesource.com/Documentation/note-db... [8] https://gerrit.googlesource.com/plugins/reviewnotes/+/refs/h... [9] https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki [10] https://git-annex.branchable.com/

In If I could make my own GitHub

stephenr·May 15, 2025

It's a little disappointing that BugsEverywhere/BE (https://github.com/aaiyer/bugseverywhere) never gained popularity. I appreciate that tools like Git Bug are not tied to a single repo host but they are tied inherently to a single VCS (git). BE was not reliant on a specific VCS, and it's a *really* simple format on-disk too.

In Git Bug: Distributed, Offline-First Bug Tracker Embedded in Git, with Bridges

Izkata·Aug 28, 2024

There were several of these in the early/mid-2010s and all had different drawbacks that made them awkward to deal with. Offhand the only one I remember the name of was BugsEverywhere: https://github.com/aaiyer/bugseverywhere Some issues I remember in general (not all of these applied to all these distributed bug trackers) that caused them to largely be abandoned: * No single view of cases: At least one of them was tied to the current commit, so a case could be resolved on a branch but not master * No central view for non-devs * Updating happened outside normal git operations so it was easy to forget to push/pull case changes * One of them that avoided the previous issue made heavy use of branches to keep its data in the main repo, so it turned the repo into a mess * Even if you did push/pull, updates aren't synchronous with a central loc

Read the rest

ation so it was totally possible for two people to assign a case to themselves locally and not realize it until later

In Taskwarrior – CLI Task Management

Izkata·May 15, 2021

Experimenting with distributed issue trackers in git was popular in the early 2010s, there were a whole bunch of different implementations people came up with for git. Most of them died out though, there were typically a few problems - this is what I remember offhand from experimenting with a whole bunch of them: * Some of them make a mess of some part of git; one of them put its info in separate git branches you couldn't delete without breaking it, to ensure changes were always pushed/pulled even without a special push/pull command for the issue tracker. * At least one of them kept their info in the repo in a dot-prefixed directory and auto added/committed the file as changes were made; this meant a single issue could be in different statuses depending on which branch you were on and there was no overarching view. * The rest effectively

Read the rest

ran in parallel to the git repo, pushing and pulling their data within it but requiring their own commands to do so, so it was totally possible to clone the repo and not get the issues. * Most of them didn't have a non-repo way to track issues, for project managers and such. One did have a webview that ran from a repo, but it was up to you to figure out how to keep it in sync with the comments/etc devs were putting in their copies of the issue tracker. Sibling mentions git-bug, a few others I recalled/quickly found: https://github.com/aaiyer/bugseverywhere (I think this is one of the original ones) https://github.com/dspinellis/git-issue https://github.com/neithernut/git-dit https://github.com/google/git-appraise (I think this one is newest and I probably never tried it)

In The Return of Fancy Tools

Izkata·Oct 25, 2020

In the early 2010s, there were a whole bunch of distributed issue trackers for git. They all died out due to various problems, such as working across branches, polluting the commit history, extra commands to keep synced (including not getting retrieved with the initial clone), not having a web view for project managers/bug reporters, etc. I think this was the most popular one: https://github.com/aaiyer/bugseverywhere

In YouTube-dl is now part of GitHub/dmca.git

Izkata·Jun 4, 2018

Somewhere around 2009-2012 there was also a lot of experimenting going on with distributed issue tracking, such as with Bugs Everywhere [0] (and like 3 or 4 others I tried some time ago that I can't find now). That said, it seems like there was a resurgence - I found two, git-issue [1] and git-dit [2], that have both had activity this year. And git-dit has shown up on here at least once before, as well [3]. [0] https://github.com/aaiyer/bugseverywhere [1] https://github.com/dspinellis/git-issue [2] https://github.com/neithernut/git-dit [3] https://news.ycombinator.com/item?id=13732598

In Microsoft Is Said to Have Agreed to Acquire GitHub