Top
Best
New

Posted by alentred 12 hours ago

Git-bug: Distributed, offline-first bug tracker embedded in Git(github.com)
286 points | 93 commentspage 3
0xbadcafebee 8 hours ago|
I considered using something like this, but instead I implemented my own basic JSONL issue tracker, and I keep the issue files in an `issues` branch in Git. This separation of concerns allows simpler design and gives more flexibility (if I want to change either git or the issue tracker, or go without Git altogether, they're not tied together).

Over the years I've noticed that "merging two designs into one" is a design smell. Nearly every technology we still use today has a very clear separation from other technologies, and is instead layered or composed to gain added functionality.

qiine 6 hours ago|
do one thing and do it well...
sscaryterry 5 hours ago||
See also: https://github.com/schacon/ticgit
bflesch 10 hours ago||
Looks really nice, I wonder why there hasn't been a project with this exact name and functionality before. When I think about it, "git bug" is quite limiting (the bug vs. feature discussion).

Naming things is hard, but I can see that it might feel unnatural to use "git bug" to track features. Maybe that's totally okay because it does one thing - tracking bugs - very well, and the whole feature roadmap is living in another system/process anyways?

Meneth 10 hours ago||
Bugzilla has been using the term "bug" to track features for nearly 3 decades now. Doesn't seem to hamper them.
iamnothere 7 hours ago||
There’s also Fogbugz, Mantis Bug Tracker, etc.
michaelmure 9 hours ago|||
I do want to extend to pull-request and more, so I'll need to at least make space in the CLI commands. Having a "git bug bug" next to a "git bug pr" is quite ugly.

Naming is hard, but I mostly didn't expect to reach that point :-)

boredtofears 9 hours ago||
Don't overthink it! `git bug bug` is fine - it's easy to type and becomes muscle memory quickly. Love the project, my first impression is "why hasn't this existed the entire time?" which usually means you're on to something.
SAI_Peregrinus 8 hours ago|||
Lack of a feature is a bug. After all, it's intended functionality that doesn't work!

It's also a denial of service, since the feature doesn't work yet, and thus should get assigned a CVE.

Towaway69 10 hours ago|||
Isn't everything nowadays a bug?

Only once it gets fixed does it become a feature.

;)

sodapopcan 10 hours ago||
Although if it doesn't get fixed, it also sometimes becomes a feature.
dizhn 10 hours ago||
Their logo is a ladybug so everything works out in the end.
cush 9 hours ago||
To me, tickets need to be too broadly accessible for anything like this to be viable. Any barrier to entry to creating tickets means people aren’t filing them. Every role at every level looks at them and edits them.

Yeah yeah we don’t want a centralized service, but it’s the ideal use case for a centralized service.

michaelmure 9 hours ago||
I agree. I'll have soon-ish the webui accept OAuth/OIDC, so you can easily host and replicate a normal bug tracker experience... yet still benefit from the other workflows that a normal forge can't have.

That's the key feature to make a distributed bug tracker actually work in practice.

cush 7 hours ago||
Wouldn't it require constantly pushing/fetching? Or would it effectively be like a hosted thing with a service layer on top of git showing a live view of the repo's tickets? Like github but for tickets... oh wait...
michaelmure 6 hours ago||
It's both really. If done well, the same local-first software can be a hosted solution and give you the "github" experience, or work fully locally, or anything in between with different topologies. If you work locally but care about some external sources, it's just a matter of notification, polling or transport. That can be done silently in the background.
cush 6 hours ago||
Right but it's all this ceremony that kind of all begs the question - why git? What's the motivation behind using git to do all this if the repository (where the code lives) and the tickets (bugs in the product created by building the code), are naturally out of sync? eg in many cases a bug can't be closed until someone verifies it's fixed, which happens after merge. The point at which a bug is marked as verified is arbitrary with respect to the commits and code. It's just a radom point in time as far as git is concerned. To me there's no need for git to be involved in any way and a url to a ticket in a commit message is far superior in terms of tracking
michaelmure 5 hours ago||
The point of using git is to have a full software project (code, issues, ...) self-contained, without being trapped in or dependent on a SaaS, dead fast and working offline and integrating with all your tooling locally. All that with a single binary and git that virtually everyone use already.

Now what you are talking about seems to be about the lifecycle of a bug. With this model you can replicate the same behavior as on major bugtrackers, or also track some metadata (fix in commit xxx) and compute where the bug is "deployed". But that's a UX/social problem, not a technical one imho.

afaraha 6 hours ago||
[dead]
khimaros 5 hours ago||
see also: https://github.com/dspinellis/git-issue
rohanat 52 minutes ago||
[dead]
jessechili 5 hours ago||
[flagged]
sahidakhtar3567 9 hours ago||
[flagged]
notloganhogg 7 hours ago||
[dead]
Godsend69 9 hours ago|
[dead]
More comments...