Oh this project again, author was getting absolutely shredded on the Go subreddit earlier today for having no clue what he is building
https://www.reddit.com/r/golang/comments/1i6v9ou/evo_a_new_v...
https://www.reddit.com/r/golang/comments/1i6v9ou/evo_a_new_v...
https://nest.pijul.com/pijul/pijul (self hosted, thus not on Github)
It uses the interesting Sanakirja db engine:
https://pijul.org/posts/2021-02-06-rethinking-sanakirja
https://docs.rs/sanakirja/1.0.1/sanakirja
When I look at the design goals of Evo, it seems to be more on the user ergonomics side. There have been many attempts to fix Git's UX; so there is probably some things about Git's UX that can be improved.
"Partial clones Commutation makes it possible to clone only a small subset of a repository: indeed, one can only apply the changes related to that subset. Working on a partial clone produces changes that can readily be sent to the large repository. "
OK, now I am interested.
I yearn for Pijul every time I want to submit multiple dependent PRs to github and then fix any not-last one in the chain.
Actually I'm not sure if it'd help at all with the github part, but at least rebasing all this wouldn't be a horror.
It is scary that someone can say it is "encrypting" a private key by applying a simple XOR.
Also :
"File-Based Index: We track file hashes in a small JSON index instead of re-hashing everything on every commit or switch. This makes commits and merges faster because Evo only re-hashes files if it notices a changed modtime"
Using modtime is not a good idea at all, this is very telling about how much author knows about different workflow. For those who don't know : you can have remotely mounted files where your machine and the server time is different (happens to me and realized that makefile is modtime based and it creates problem), also obviously clock can change and you do not want your version control system to be blind on changed file, ever.