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.
Show HN: Epiq – Distributed Git based issue tracker TUI
41–50 of 59 posts
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#42Earlier quoted context omitted.
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 work…
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?
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#43@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.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#44Earlier quoted context omitted.
There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who…
[flagged]
[deleted]
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#45Earlier quoted context omitted.
There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who…
[flagged]
[deleted]
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#46Earlier quoted context omitted.
There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously: > You're offering a retort to someone who…
[flagged]
I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#47Earlier quoted context omitted.
[flagged]
I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".
Check the comment history.
You're currently being trolled.
Also, thank you for your work.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#48There 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…
Isn’t splitting code and meta into two repos the same solution here? Like how GitHub tracks your Wiki in a separate repo (which you could repurpose for your issues, even).
The ones in those first two bullets made issues part of the repo so you'd clone/push/pull updates automatically with the normal git commands. They were trying to reduce friction with usage: Fewer new commands to remember/use, local data so the commands were instant like "git commit" or "git show" are, and automatic syncing but only when the user was already doing it so there wouldn't be unexpected hangs if the remote was inaccessible for some reason. Putting them in the same repo also meant since they came along with every normal git clone, every repo had a copy regardless of if a specific user had the tool or not, so switching between hosts would never be an issue and would automatically be supported without having to update however the two repos were linked.
The one that tied issues to specific commits I think even portrayed the different-states-in-different-branches as a feature, that for example you could easily tell at a glance whether a bug had been fixed on the branch you're on or not. This was also the era when people were figuring out complex branching strategies like gitflow, where that would be a reasonable thing to be uncertain of.
Like I said the problems were part of the design, not incidental, the tradeoffs just ended up not what people wanted.
Also something else I didn't mention before, all of these were command-line, not TUI. I have no idea how that would've changed the result. For example I could imagine automatic background syncing actually being reasonable, sidestepping some of the issues the command-line ones had to work around.
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#49@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.
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!
Re: Show HN: Epiq – Distributed Git based issue tracker TUI
#50As 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.