Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Epiq – Distributed Git based issue tracker TUI

ljtn.github.io

Post reply on HN
Print view View original

31–40 of 59 posts

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

#31

Post by jolaflow »

eterps wrote: post #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?

That is a known limitation as of now. Text updates are currently handled as whole chunks, so Epiq does not implement character-level CRDT merging.

In the event of conflicting updates to the same text block (currently title or description fields), later events take precedence.

What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.

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

#32

Post by cxr »

locknitpicker wrote: post #18
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…

> It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.

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 is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]:

> Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

> Person B: Yet people smoke

https://news.ycombinator.com/item?id=38712699>

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

#33

Post by captn3m0 »

Izkata wrote: 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…

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

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

#36

Post by locknitpicker »

cxr wrote: post #32
locknitpicker wrote: post #18

Earlier quoted context omitted.

> It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs. You're talking about node.js projects running on node.js, and you're complaining that it consumes node.js APIs. Strange.

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]

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

#37

Post by [deleted] »

eterps wrote: post #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?

[deleted]

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

#38

Post by eterps »

jolaflow wrote: post #31
eterps wrote: post #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?

That is a known limitation as of now. Text updates are currently handled as whole chunks, so Epiq does not implement character-level CRDT merging. In the event of conflicting updates to the same text block (currently title or description fields), later events take precedence. What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previo…

> What you can do is use commands like ":peek prev" (takes you to the previous edit), ":peek 1h", or other time-travel commands to inspect previous states and manually recover overwritten changes if needed.

Thanks, I think that would work fine in most cases if you can open your editor with the 'prev' version and the current version in 2 panes (or in diff mode).

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

#40

Post by targetbridge »

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.
Post reply on HN