HN Explorer

Show HN: Epiq – Distributed Git based issue tracker TUI (ljtn.github.io)

91 points by jolaflow ↗ HN
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.

26 comments

[ 3.1 ms ] story [ 58.5 ms ] thread
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.

SidVikJay
Really elegant solution to the distributed issue state problem. Using user-scoped immutable event logs to prevent git conflicts is a clever architectural choice. Congrats on the launch!
eterps
> Conflict handling model: Later events take precedence when conflicts occur

Do I understand correctly that if 2 people add a lot of information to one issue only one of them 'wins' and becomes visible? Or is it more subtle?

If only the latter one becomes visible, how do you get to the edits of the other person and 'merge' it again?

aniceperson
cool Project but global npm install is a no for me, and there seem to be no similar to python venvs in node.js ecosystem.
eddy-sekorti
Looks good, i will try this out
jolaflow
Thanks! Id be happy to hear what you think after trying it out!
targetbridge
As a web developer, the local web server UI idea sounds like the natural next step. Since you're already using Ink/React for the TUI, the component model should map well to a browser-based UI. The git-as-database approach is elegant — curious to see how it evolves.
jolaflow
Thank you! I too am excited about next steps. There are a lot of interesting paths to explore still, and I do agree that the web interface would be a natural evolvement.
targetbridge
I know of a few projects that have used Git as a database to parse ETF flow data after extracting it and saving it in JSON or CSV format.
quantummagic
Obviously you should be free to develop anything you want, using any tools you want. But the installation instructions featuring "npm" as the first step, means a hard pass for me. We have to stop building on quicksand.
dmos62
@jolaflow looks great. What motivated you to build this? If you wanted TUI issue tracking and CLI/MCP interfaces, I imagine there's already a lot of tools for that.

To be clear, I'm really into this. I'm using a custom git-based agent and this is a viable replacement for its issue tracking.

jolaflow
Thanks for the kind feedback! My initial motivation was of lack ergonomics in the tools I used. I had a vision of what I wished issue tracking was like, and the tools we were using were nothing like that. In my opinion they were hard to navigate, slow, unreliable and prompted you to login every once in a while. I thought I’d be able to make something useful in a weekend. It took me a year of on and off coding, but its been a great journey!
pixel_popping
I'll be honest, cool yes, but forget about adoption, the first impression is that it's just a quick thing that is meant to die due to its copycat design, which downgrade the seriousness of the project itself.