Back to News
Advertisement
jjolaflow about 5 hours ago 8 commentsRead Article on ljtn.github.io

RU version is available. Content is displayed in original English for accuracy.

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.
Advertisement

⚡ Community Insights

Discussion Sentiment

43% Positive

Analyzed from 428 words in the discussion.

Trending Topics

#git#issue#state#web#distributed#data#user#branch#agent#already

Discussion (8 Comments)Read Original on HackerNews

Izkataabout 3 hours ago
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?

jolaflowabout 3 hours ago
Thanks for input. Interesting list. A few notes on that:

- Issue state is not tied to commits in the checked out repo. Events live in append-only user-scoped logs and are materialized independently of the checked out branch, so switching branches does not change issue state. This is solved with git worktrees.

- Epiq keeps state in a dedicated state branch and does not put issue data into normal code history. The working branch stays clean.

- Sync uses normal git push/pull semantics.

- Multi-user conflicts are prevented because each user writes only to their own immutable event log file. You never co edit a file. Logs converge state in memory from the combined event stream. There’s no shared mutable issue document being edited.

- The non-developer distribution can be addressed with exported state .md files (with the board as ascii). They are currently not generated automatically, but you can generate them at will. [edit - addition: Considerable effort has also been put into making the tool accessible to non-technical people, so there is auto completion, hints, a command palette with descriptions of each command, arrow key navigation and so on. It is my hope that anyone can pick it up rapidly. And a web interface could definitely be crafted for that usecase]

nextaccounticabout 1 hour ago
> 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

joshkaabout 1 hour ago
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.
joeblubaughabout 2 hours ago
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
jolaflowabout 2 hours ago
Good point. A local web UI is probably one of the highest priorities from here. The UI, persistence and materialization layers are already fairly separated architecturally.

The current TUI is built with Ink, which is a React renderer for the terminal, so conceptually the UI structure already maps naturally to the web.

samuellabout 4 hours ago
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.
jolaflowabout 3 hours ago
Thanks!