Hacker News new | ask | show | jobs
by Izkata 1310 days ago
Around 2010-2015 there were a whole bunch of these distributed git bugtrackers and none of them took off. Most are completely dead. IIRC one of the biggest problems was its feature: issue state being distributed as it is, it was very easy for developers to end up with issues having different states/comments, and depending on the implementation even differed across local branches. But also in a work environment there was no place for project managers to view/create/update issues.

I remember listing out 4-5 of these in the past when the topic has come up, but the only old one I can remember/find right now is https://github.com/dspinellis/git-issue

Edit - Found some more using duckduckgo instead of google:

* https://github.com/jashmenn/ditz (last update 12 years ago)

* https://bugseverywhere.org/ (I think this was the most popular at one point)

* https://github.com/marekjm/issue (this is separate from git-issue above)

* A blog post from 2012 that lists these and a few others (half the links are dead): http://www.cs.unb.ca/~bremner/blog/posts/git-issue-trackers/

From the blog post, the additional ones where the links still work:

* https://github.com/chilts/cil (last updated 11 years ago)

* http://syncwith.us/sd/ (last updated 6 years ago)

3 comments

more generally I think you're right about large teams needing a 'source of truth' that is complex (includes feedback from different layers of mgmt, includes user / real life bug feedback, capable of producing estimates, plays well with product design framework)

teams that have like anaplan and figma in their stack probably cannot use this

but for a team that would otherwise be using github issues for project mgmt, I don't think the in-git approach is awful

2015 was before Microsoft bought GitHub. There has been some movement to use other forges since then so I don't think this will have to fail to catch on just because it did before.
Yeah, I agree. I'm not against making it a built-in, but it seems to cater to a tiny usecase that I don't have. Maybe it's more people than I know, though.
I think it's more that its a use case that you don't know yet you have. Like backups, the need for having an exit plan from a centralized bug tracker often only becomes apparent when it is already too late.