> It's designed the way it is to achieve that goal while minimizing the space used, yet keeping an entire history of the project
Most of git's design was done before they thought of 'minimizing the space used'. Originally, they didn't even do deltas and just stored complete snapshots for every object.
> Merge conflicts are hard in this model because you're trying to put two snapshots together, not just two diffs.
I don't think that's the case at all. Thanks to three-way-merges git has just as much access to the diffs as any other version control system when merging. It's just that in git diffs are a derived data structure, not a source of truth, but that doesn't make a difference.
I get the feeling that depends on who you ask at this point, but there has apparently been some recent development of the hosting platform (https://nest.pijul.com/). I don't know if it can have as good of a Git interoperability story as, say, jj.
I am not interested that much in interoperability with Git.
But I am afraid of data corruption, crashes, etc.
Also, Pijul used to have severe performance problems in some situations.
I would call it ready for production if it is stable and performant.
Git interoperability can help with that: if you have an on-disk data format that's either compatible with git, or can easily be converted to git, you can keep your backups in git format, and work from them with git if something goes wrong.
Most of git's design was done before they thought of 'minimizing the space used'. Originally, they didn't even do deltas and just stored complete snapshots for every object.
> Merge conflicts are hard in this model because you're trying to put two snapshots together, not just two diffs.
I don't think that's the case at all. Thanks to three-way-merges git has just as much access to the diffs as any other version control system when merging. It's just that in git diffs are a derived data structure, not a source of truth, but that doesn't make a difference.