Show HN: Epiq – Distributed Git based issue tracker TUI
Issue trackers typically live outside of your workflow, with poor ergonomics. Epiq aims to solve that, bringing issue tracking into your terminal. Multi-user collaboration is achieved via git using user-scoped immutable event logs that converge in memory. Put my all into it. Let me know what you think.
Discussion Highlights (7 comments)
samuell
I think this is a cool project. I see a lot of use cases for this, for cases where it is preferable to keep issues local to the repo, distributed via git only, and not the least for all kinds of personal task management. Avoiding the context switching to a web based tool is a nice plus.
Izkata
There was a small surge in popularity in distributed git issue trackers a bit over a decade ago, and all of them had some sort of problem baked in to the design that made them not very good. Two weeks ago I had listed out the problems I could remember offhand: https://news.ycombinator.com/item?id=47956979 It sounds like there's intentionally no attempt to handle the last one (that this is by devs for devs), and points 3 and 4 might be addressed somehow since it mentions syncing automatically. Does it store data separate from git to avoid the first two?
joeblubaugh
It’s very slick, but I would be interested to know how separable the UI and the data layer are. I love vim but asking a collaborative group to all use a TUI is difficult. A local web server would be a nice alternative UI
joshka
I really like the idea of a distributed issue tracker. I'd encourage you to look at git-bug if you haven't already done so for some prior art / inspiration / hard learned lessons.
nextaccountic
> Agent interactions > The MCP server lets AI tools interact with Epiq in a predictable way. Or maybe just publish a skill for the agent to use your CLI? The agent alredy uses CLI commands to interact with git itself
swoorup
I would prefer a single binary and skill over mcp.
goyozi
You have my upvote because I love Git-based apps. There’s something cool about Git being an effective database with loads of free hosting options. I’d (re)consider a couple of things if you intend to work on it and make it viable for a wider audience. 1. Who is it aimed for? If product managers and designers _are_ in scope e.g. you imagine full engineering teams using it, then a TUI isn’t gonna cut it. It’s a great interface choice for devs but I don’t think it’s organizationally viable to force everyone else in the terminal. 2. I’d think about either having a central issues repository as a default / recommended option or creating an easy way for linking issues together across repos. To me, as appealing as it sounds to have your code and issues together, these things often evolve at a different pace. If I want to edit an issue I’m working on to add some new info or address changing requirements, I almost definitely don’t want to commit and push it with my local WIP version of the code.