Live data from Hacker News

Show HN: Epiq – Distributed Git based issue tracker TUI

ljtn.github.io

21–30 of 59 posts

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

#21
post #14

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…

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

#22
post #3

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 point…

[deleted]

Re: 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

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.

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

#27
post #3

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 point…

Out of things listed there, I see some as positives rather than negatives, but, specifically, wanted to reflect on:

> 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

#28
post #14

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…

Thanks for the upvote!

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

#29
post #14

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…

Quick note The TUI is so well made, it seems easily useable by anyone who seriously wants to.

Thanks for the encouraging input!

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

#30
> 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?

Post reply on HN