And none of them actually work really well. This blog post is over ten years old, but the situation didn’t improve much https://matej.ceplovi.cz/blog/current-state-of-the-distribut...
replyNo mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.
replyIt may be that the presence of Fossil as a mature option is enough to dissuade people from choosing/working on alternatives. I’m pleased to see git-bug slowly making progress though, maybe it will get there in time.
Thanks for reminding me of Fossil. I've been developing something locally and keeping track of things in a text file.
replyHits hard.
replyI looked into them. Most of them use some CRDT-ish machinery to merge concurrent ticket changes. (Fixing merge conflicts in tickets would be too disappointing.) As a CRDT person, I noticed that implementing CRDT merges in git itself mostly makes that machinery unnecessary. Then you can keep your tickets in plain Markdown, having CRDT merges for both code and metadata. I have it working here btw
There is an alternative to auto-resolution or fixing low-level git merge conflicts. In my git forge Haxy, I am detecting conflicts in local-first metadata and allowing you to fix them in the UI. This is possible because I am not doing a line-based merge; the issues are stored as a data structure, so I can see what specific parts are in conflict. This allows a much nicer form of conflict resolution than conflict markers in a text file. I demoed this here: https://www.youtube.com/watch?v=kkGUARj5Wdw and here's the project: https://github.com/xit-vcs/haxy
replyWell written blog post! I enjoyed reading it.
replydeleted
reply