remenoscodes

6 ms·

1. 1.▲
   by remenoscodes 7mo ago

   Just saw this — I posted a different take on the same problem the same day (git-native-issue, commits instead of files). Two independent projects converging on refs/issues/ is good signal. The markdown files approach gives you gre
2. 2.▲
   by remenoscodes 7mo ago

   Cool, just looked at git-pad. Same day, different data models for the same problem. Independent convergence is a good signal. On why empty commits: this started with Linus's 2007 rant about wanting "a git for bugs." I took it
3. 3.▲
   by remenoscodes 7mo ago

   Thanks for weighing in — git-bug is in the spec's Acknowledgments and Section 10.2 for good reason. The DAG topology → Lamport clocks → hash ordering hierarchy is cleaner than LWW. And the signing point is shared ground, since git-nati
4. 4.▲
   by remenoscodes 7mo ago

   Good catches, thank you. Timestamps: You're right that the current merge uses committer timestamps (LWW), and clocks can disagree. The spec is explicit about this tradeoff — Principle 4: "Last-writer-wins over Lamport clocks.&quot
5. 5.▲
   by remenoscodes 7mo ago

   Yes! git-bug is the closest prior art, I reference it in the README's Prior Art section. Three key differences: 1. Plain Git primitives — git-bug uses CRDTs with JSON operation logs. git-native-issue uses commits as events, Git trailer
6. 6.▲
   by remenoscodes 7mo ago

   I built git-native-issue ( https://github.com/remenoscodes/git-native-issue ), a distributed issue tracker that stores issues as Git commits under refs/issues/. In April 2007, during a flame war about the Linux
7. 7.▲
   Show HN: Git-native-issue – issues stored as commits in refs/issues/(github.com)

   9 points by remenoscodes 7mo ago|10 comments