3 ms·
Impressive work. I built something similar and clearly remember the design choices I made, so this is an interesting subject. On CRDTs: I assume tools like git
by kwhkim 7mo ago
Impressive work. I built something similar and clearly remember the design choices I made, so this is an interesting subject.
On CRDTs: I assume tools like git-bug adopted CRDTs primarily to avoid merge conflicts, but "last-writer-wins" via timestamps is risky — clocks are notoriously unreliable or set incorrectly. While CRDTs aren't "accurate" either, they do their best to converge. Personally, I'm uncomfortable with systems that silently overwrite edits when multiple people change the same issue differently. If two users modify state concurrently, I'd rather see an explicit conflict than an automatic resolution.
Related to that, I couldn't fully determine from the docs how your merge behavior works in practice. It seems like there are no conflicts, but how they are resolved is unclear to me. This is easily one of the hardest design decisions in a distributed issue system. One approach might be restricting certain edits (e.g., only authors can modify specific fields) or explicitly raising conflicts when a semantic disagreement occurs. I prefer the latter. With the help of AI, we could likely distinguish semantic conflicts from trivial syntactic differences (like LF vs. CRLF).
Regarding UUIDs: I understand why Git uses hashes — collision avoidance is critical in a distributed system. However, from a UX perspective, long, opaque identifiers are difficult to remember or reference in conversation. I've explored using shorter, human-friendly identifiers that still minimize collisions. I think Ergonomics matter immensely if this is intended for daily use.
A practical concern: using custom refs per issue can clutter the namespace. In tools like VS Code's Git graph, enabling "Show Remote Branches" causes remote issue refs to appear visually, adding significant noise. It's not a dealbreaker, but it does affect usability in some Git clients (speaking from my experience with git-bug).
Broadly speaking, I'm still undecided about storing issues directly as Git commits. Whatever the merge policy or conflict resolution strategy, it can be implemented in a custom merge engine (I think — and it's on my to-do list). You can track how issues evolved over time with commits, but it makes managing them in batch or bulk more difficult. A file-based system can achieve the same effect using `git log -- $FILENAME`.
That said, I really like that you extracted a standalone ISSUE-FORMAT.md. A format spec that outlives the implementation is arguably the most important part of this effort — especially if it includes a specification for attachments. Even though I'd prefer the issue format to be more flexible and casual, trying to establish a standard is worth the effort.
- michaelmure 7mo ago> On CRDTs: I assume tools like git-bug adopted CRDTs primarily to avoid merge conflicts, but "last-writer-wins" via timestamps is risky FYI, git-bug doesn't use timestamps to figure out the ordering. It first uses the git DAG topology (it defines ancestors), then Lamport clocks (increment for any changes on any bugs), then order by hash if there is still an ambiguity. Note that the git DAG could also be signed, which would also provide some form of reliance against abuse. I had an interesting discussion recently about how to handle conflict for bug trackers. In my opinion it's a great use-cases for CRDTs (as it avoids data corruption), as long as all user intents are visibly captured in a timeline and easily fixable. It turned out though that there is an interesting middle ground: as the CRDT captures *when* a concurrent editing happen, it's 100% doable to highlight in the UI which event are concurrent and might need attention.
- remenoscodes 7mo agoThanks 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-native-issue uses standard commits, GPG/SSH signing works out of the box for the same abuse-resistance property. Your "middle ground" observation — that CRDTs naturally reveal when concurrent edits happened — is the part I find most compelling. The format spec reserves a Conflict: trailer (Section 6.8) for a similar idea: flag divergent edits for human review rather than silently resolving them. The current v1 resolves everything automatically via LWW + three-way set merge. The honest gap: LWW can detect that a divergence happened (via merge-base), but it can't express the causal relationship between events the way Lamport clocks can. That's a real limitation. The design bet is on adoption surface. The spec uses only commits, refs, and trailers primitives that any Git hosting platform or TUI already understands, with no new dependencies. My hope is that a simpler format gets more implementations, and more implementations make portable issue tracking real. But I take your point that "simpler" isn't automatically "better for users" when it comes to concurrent editing. On interop — the spec says a bridge would be "straightforward" (Section 10.2). That's probably too optimistic. git-bug's operation log doesn't map cleanly to linear commit chains, and a lossy bridge helps nobody. Worth exploring more carefully though, if there's interest on both sides.