4 ms·

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

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_version_control_system_written_in_go/ https://www.reddit.com/r/golang/comments/1i6v9ou/evo_a_new_v...

kajika91 2y ago
Thanks for the heads up, there are indeed incredibly bad things in that project as linked by the top comment (with the simple word "bruh...") : https://github.com/crazywolf132/evo/blob/15d2ec6e821ef221961925e4899c545ec660fcbe/internal/core/signing.go#L98-L108 https://github.com/crazywolf132/evo/blob/15d2ec6e821ef221961... 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.
- user3939382 2y ago
  Maybe someone could politely explain it to him then instead of the condescending, alienating snark for which the computing community is infamous.
- JTyQZSnP3cQGa8B 2y ago
  He made a fix in https://github.com/crazywolf132/evo/commit/2452bec536d9b4d60687eaba1c358505e928f718 https://github.com/crazywolf132/evo/commit/2452bec536d9b4d60... but he converted the indentation at the same time, and does not PRs at all. It's dangerous amateur stuff.
cies 2y ago
There's a Rust project (used to be OCaml iirc) that aims to be a better Git, it's called Pijul. https://pijul.com https://pijul.com https://nest.pijul.com/pijul/pijul 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://pijul.org/posts/2021-02-06-rethinking-sanakirja https://docs.rs/sanakirja/1.0.1/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.
- kajika91 2y ago
  I find the "why" points not appealing to me (maybe I know my way around git too much), but one: "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.
  - baq 2y ago
    > I find the "why" points not appealing to me 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.

kajika91 2y ago

Thanks for the heads up, there are indeed incredibly bad things in that project as linked by the top comment (with the simple word "bruh...") : https://github.com/crazywolf132/evo/blob/15d2ec6e821ef221961925e4899c545ec660fcbe/internal/core/signing.go#L98-L108 https://github.com/crazywolf132/evo/blob/15d2ec6e821ef221961... 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.

user3939382 2y ago
Maybe someone could politely explain it to him then instead of the condescending, alienating snark for which the computing community is infamous.
JTyQZSnP3cQGa8B 2y ago
He made a fix in https://github.com/crazywolf132/evo/commit/2452bec536d9b4d60687eaba1c358505e928f718 https://github.com/crazywolf132/evo/commit/2452bec536d9b4d60... but he converted the indentation at the same time, and does not PRs at all. It's dangerous amateur stuff.

cies 2y ago

There's a Rust project (used to be OCaml iirc) that aims to be a better Git, it's called Pijul. https://pijul.com https://pijul.com https://nest.pijul.com/pijul/pijul 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://pijul.org/posts/2021-02-06-rethinking-sanakirja https://docs.rs/sanakirja/1.0.1/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.

kajika91 2y ago
I find the "why" points not appealing to me (maybe I know my way around git too much), but one: "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.
- baq 2y ago
  > I find the "why" points not appealing to me 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.