[kevincox]

The feature I think I would most like to see is support for patches as a more first-class object. For example reverts and cherry picks have no real metadata. This leads to conflicts when merging branches that have cherry picks (although they often auto-resolve if they are exactly the same diff) and makes asking "Does $branch contain $patch" basically impossible to answer.

https://pijul.org/ greatly improves this by making patches a first class object (and commits are basically sets of patches). I think it has some great ideas to improve the really gnarly parts of Git low-level behaviour. (Not just surface-level UI issues)

[oneofthose]

Is there a design doc one could study? At a high level I understand how the fact that patches are commutative is elegant, but it seems to me there are performance impacts when, to get to a repository state, we have to apply many patches. Would love to read how pijul thinks about that.

[pmeunier]

This is indeed one of the issues of Pijul, but patch application is extremely fast, which makes it easy in the vast majority of cases (we don't apply patches to files directly, but to an on-purpose on-disk datastructure).

We also have a tag features, allowing you to pinpoint versions and go back instantly, and we have plans to make that feature even lighter on disk space.