← Back to context

Comment by mcepl

11 hours ago

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...

6 comments

mcepl

Reply
iamnothere  8 hours ago

No mention of Fossil, which works great and proves that the difficulty is in gathering dev interest.

It 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.

  • int_19h  26 minutes ago

    Fossil is very opinionated about some things, in particular, the inability to rewrite history, which makes it a non-option for some. So there's still a niche for Git-based distributed bug tracking.

  • vips7L  7 hours ago

    Thanks for reminding me of Fossil. I've been developing something locally and keeping track of things in a text file.

gritzko  10 hours ago

Hits hard.

I 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

https://replicated.live/blog/meta

  • xeubie  5 hours ago

    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