Show HN: Epiq – Distributed Git based issue tracker TUI • Hacker News Board

jolaflow wrote: post #51

eddy-sekorti wrote: post #35

Looks good, i will try this out

Thanks! Id be happy to hear what you think after trying it out!

Yes, sure, i have sent it to my developer and will give you feedback, noticed onething, https://ljtn.github.io/epiq/ since it will also be used in enterprises, you need to show them you are secure and compliant, you can setup a free trust center via sekorti dot com it takes less then 30 mins to be enterprise ready. Let me know if you are intetested and i will upgrade your account for free.

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#54

Post by pauxel » Sat, May 16, 2026, 8:20 PM UTC

[dead]

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#55

Post by cxr » Sat, May 16, 2026, 8:53 PM UTC

hiccuphippo wrote: post #42

cxr wrote: post #12

Earlier quoted context omitted.

You don't need to put it on the Web to be able to leverage the World Wide Wruntime. Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser. If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured s…

How can the browser execute git commands from opening a local html file? Maybe if you give the file a different extension and configure an application to run a webserver and open the default browser when the file is double-clicked?

> How can the browser execute git commands from opening a local html file?

It can't. The CONTRIBUTING.html shell would spit out a file and tell the user what Git commands need to be run—just like project READMEs (or landing pages like jekyllrb.com) show which commands will install the tool.

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#56

Post by nextaccountic » Sun, May 17, 2026, 12:19 PM UTC

jolaflow wrote: post #24

nextaccountic wrote: post #10

> 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

It's mainly about robustness and deterministic outcomes. There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.

Maybe add --something to make your output agent-friendly then? MCP adds a lot of token overhead and is not pipeable, that is, you can't do mcpserver1 | something without the tokens first passing into the context window of the agent (if you use a subagent it's the same thing - you are still spending the tokens)

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#57

Post by pixel_popping » Sun, May 17, 2026, 3:33 PM UTC

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.

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#58

Post by phatskat » Mon, May 18, 2026, 11:20 PM UTC

nextaccountic wrote: post #56

jolaflow wrote: post #24

Earlier quoted context omitted.

It's mainly about robustness and deterministic outcomes. There is a small level of noise in TUI output, and structures that are easily parsed by a human can be ambiguous for an agent (for instance column layouts). You could definitely let agents interact with Epiq purely through the CLI, but the idea behind the MCP server is to provide stable, predictable interfaces where determinism matters.

Maybe add --something to make your output agent-friendly then? MCP adds a lot of token overhead and is not pipeable, that is, you can't do mcpserver1 | something without the tokens first passing into the context window of the agent (if you use a subagent it's the same thing - you are still spending the tokens)

I think I can understand what you want, and the dev’s response about deterministic output is something I really appreciate. I don’t think I want an agent going and mucking around in git _at all_, and if it is going to, I’d prefer some level of predictability imo.

Re: Show HN: Epiq – Distributed Git based issue tracker TUI

#59

Post by targetbridge » Wed, May 20, 2026, 6:38 PM UTC

jolaflow wrote: post #50

targetbridge wrote: post #40

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.

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.

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.