Hacker News Reader

Comment by Izkata | Hacker News Reader

A few months ago there was another of these posted, called Epiq: https://news.ycombinator.com/item?id=48155570

My comment on there is about a surge in popularity of these over a decade ago, with a link to a previous comment about problems I remember them having that prevented them from being usable for most people ( https://news.ycombinator.com/item?id=47956979 ), because of their intended design rather than an implementation issue. For example bullet 3 was a problem in one, that another tried to solve with bullet 2.

I don't have time right now to look at this one to guess if these apply, but might be interesting/useful for someone else.

View on HN

Other than the first bullet point in your list[1], my contribution in this regard addresses everything else.

Don't have a link handy but it's on github called "rotsit" (revenge of the something issue Tracker).

‐----‐------

[1] That's the entire point of having the issue tied to a branch: if an issue is marked resolved in the branch you are looking at, then its resolved in the branch you are looking at. Storing the issues independent of branch means you need to also store extra metadat about which branch it is broken on.

The issue there was collaboration, one person would be on master and see no hint that a case was already being worked on (status, comments, etc all being different until the branch was merged). The other bullets, that put the information in different locations, were attempts to deal with this.

I can somewhat understand your point about issues tied to branch, but have some remaining questions about how this working in practice:

- If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed

- I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch? Is it on the reporter to correctly identify the root branch where the issue was first created? Do you have to somehow merge to make this work "right"?

I haven't actually tried in practice (across a team I mean), but:

> - If I am on a branch where this issue exists and unaddressed, is it easy to find out if there is another branch where this issue has been addressed

I do not have a solution for that.

> - I am on a branch that does not have the issue reported, but know it's reported on another branch -- does that mean the issue doesn't exist on this branch?

The idea was to create issues only on on a separate branch which is constantly merged into master. Then all branches downstream of master will get the issue when they rebase/pull.

Scenarios:

1. You're on branch `x/y/z`, you notice something that should be added to the issue tracker, you stash, switch to `/issues`, add the issue, push, switch back to `x/y/z` and pop.

2. An issue is to be created, the creator clones `/issues`, creates the issue, and pushes.

This way, all issues are on all branches, but only the branch dealing with an issue will update it.

Reply on news.ycombinator.com