Hacker News Reader

It's both really. If done well, the same local-first software can be a hosted solution and give you the "github" experience, or work fully locally, or anything in between with different topologies. If you work locally but care about some external sources, it's just a matter of notification, polling or transport. That can be done silently in the background.

View on HN

Right but it's all this ceremony that kind of all begs the question - why git? What's the motivation behind using git to do all this if the repository (where the code lives) and the tickets (bugs in the product created by building the code), are naturally out of sync? eg in many cases a bug can't be closed until someone verifies it's fixed, which happens after merge. The point at which a bug is marked as verified is arbitrary with respect to the commits and code. It's just a radom point in time as far as git is concerned. To me there's no need for git to be involved in any way and a url to a ticket in a commit message is far superior in terms of tracking

The point of using git is to have a full software project (code, issues, ...) self-contained, without being trapped in or dependent on a SaaS, dead fast and working offline and integrating with all your tooling locally. All that with a single binary and git that virtually everyone use already.

Now what you are talking about seems to be about the lifecycle of a bug. With this model you can replicate the same behavior as on major bugtrackers, or also track some metadata (fix in commit xxx) and compute where the bug is "deployed". But that's a UX/social problem, not a technical one imho.

Sorry I just don't get it. It's a massive problem when a designer needs permission to force push to a repo to update a bug. These boundaries exist for a reason.

Reply on news.ycombinator.com