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 i…
Show HN: Epiq – Distributed Git based issue tracker TUI
21–30 of 59 posts
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#22There 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 point…
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#23Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#24> 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
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.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#25I would prefer a single binary and skill over mcp.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#26Really 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!
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#27There 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 point…
> No non-developer UI for project managers to see or comment on issues.
Strategically, I'd prefer this over anything that offers non-developer UI. My experience with any tool that offers non-developer UI for developer-related activities was overall infuriatingly negative (think Jenkins, JIRA, Github and the likes etc.) Because these UIs will usually expose the underlying functionality in a bad way that will create pathologically bad practices that will require the developers to accommodate the lowest common denominator.
Here's one example: Github or GitLab PR management interface. Before this became "standard practice", PRs used to be deal with from the interface to Git chosen by the developer. It allowed more freedom of editing and communication, but, most importantly, it didn't lock the developers into a few selected choices of reconciling the new changes with the existing code.
GitLab, for example, doesn't even offer the only good way to do that: there's no way, using GitLab interface to rebase the suggested changes on the target branch. All the options it offers in UI are wrong. And yet, companies, like the one I work for, make it a corporate policy to work exclusively through this garbage UI because they make their OPs / IT teams design workflows around it.
As an aside: if a project manager cannot use Git, they shouldn't be a project manager. There are some job requirements that one must meet in order to hold a job, and using the most popular VCS should be one of them. This is just as true as it is true for developers: if they don't know / can't use Git, they shouldn't be in that role. The manager's ineptitude shouldn't be an excuse to make / adopt cruddy software.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#28You 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 i…
Let me address these:
1. I envision people already comfortable with the terminal as the first to pick it up, but as someone else pointed out, a considerable amount of effort has gone into lowering the threshold and making it usable for people with limited command-line experience. I can also definitely see a future web UI being added over time.
2. There is no requirement to run Epiq alongside your codebase - you could also use a separate repository dedicated to issue tracking. When you run epiq, it traverses upward until it finds the nearest project definition. In theory, you could initialize Epiq at a higher-level scope and have multiple child repositories share the same board state, although that setup has not been officially verified or supported yet, so I would wait until there is a version that explicitly supports it.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#29You 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 i…
Quick note The TUI is so well made, it seems easily useable by anyone who seriously wants to.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#30Do 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?