As for the merge conflict, you resolve it the same way you would with any other file in git. I think a custom merge driver needs to be developed eventually — for example, automatically picking `type: bug or feature` instead of leaving the raw conflict markers like the following— but that's not implemented yet.
* It will produce a merge by default, but you can use `git pad merge --rebase` to rebase when possible. I thought a lot about this — "Do I need linear commits whenever possible?" I understand linear commits are easier to read, but I don't see other problems with merges per se. I think "who cares? No one will look at previous commits anyway." But there could be some friction — do you have anything specific in mind? Besides, you can use `git pad merge --rebase --audit` to tag the original commit before rebasing, for auditing purposes.
* It basically comes down to how many alphabets you need to guarantee no collision. Git's hashes have some probability of collision too. I don't recall the exact numbers, but for 100–1000 repos the chance of a repo-ID collision is extremely low. In the rare case of a collision, you can delete the `.local-repo-id` file and regenerate it. You would get merge conflicts though, so you'd need to reset to before the merge and rename the files. This is not implemented yet but people could do it manually using git commands and other linux commands.
It shows that I posted just a little later than you.
I agree that the chances of something going wrong with timestamps are low, but I still think it’s worth considering as a potential security risk or injection vector — although I’m not sure how realistic that threat actually is.
Regarding UUIDs, you can get the best of both worlds: sequential IDs are convenient, and adding a small number of random characters can help avoid name collisions. Since the random component only needs to ensure uniqueness across local repositories, it doesn’t require many characters.
I can see that you’ve put a great deal of effort into this, especially with the various bridging components. I built a simple bridge myself and ran some tests using the pandas project (https://github.com/pandas-dev/pandas
), which has more than 30,000 issues. Even storing only metadata (such as title and type, excluding the body) as plain text takes more than 100 MB, which seems quite large. In comparison, storing the same data in SQL takes only about 10 MB, and packed Git objects are comparable.
So while storing issues as Git commits certainly has some benefits, I don't see much advantage beyond that. It also seems that most users would not be able to make practical use of this approach easily — for example, for batch processing — unless they are already quite comfortable working directly with Git commits.
I'm curious about what considerations led you to decide to store issues as empty Git commits. I would appreciate it if you could share your reasoning with me.
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.
<<<<< type:bug ==== type: feature >>>>>>