Refusing to use PRs

Posted Jan 12, 2026 10:02 UTC (Mon) by Lennie (subscriber, #49641)
In reply to: Refusing to use PRs by alx.manpages
Parent article: Evans: A data model for Git (and other docs updates)

Something I keep wondering...

At the moment we have tools like Github and Gitlab automatically create a Markdown-based wiki:

some_project.git becomes some_project.wiki.git

Why of why, don't we have this too ?:

some_project.git becomes some_project.issues.git

This means we can replace the medium (email or web interface, etc.) and we don't depend on the tool (email client or web interface) anymore either.

Maybe people need to agree on some format. Or maybe it first needs to be part of git itself, so people can agree on it and adopt it ?

to post comments

Refusing to use PRs

Posted Jan 12, 2026 10:14 UTC (Mon) by Lennie (subscriber, #49641) [Link] (1 responses)

I should add, maybe git-bug already solved most if not all of that.

Refusing to use PRs

Posted Jan 12, 2026 19:52 UTC (Mon) by mathstuf (subscriber, #69389) [Link]

You still need some kind of separate infrastructure to do things like:

- needs some kind of side database for accounts (forges provide this for their project metadata already)
- notify users when activity on an issue they're "subscribed to" (more metadata one would want to track) changes (after all, maybe they want email notifications too!)

I've come to the conclusion that issue trackers (all of them) are terrible for *task* tracking because of the disparity in sources. Not all of my work happens on a single forge (or even any forge at all!). The devtodo tool I wrote pulls things in for Github, but other forges shouldn't be too hard. However, they are invaluable for *coordination* with other developers and users, so some kind of public activity should be visible eventually.