|
|
|
|
|
by remenoscodes
111 days 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-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. |
|