Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Evo: Version control that works the way you think

github.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Evo: Version control that works the way you think

#31

Post by kajika91 »

voidfunc wrote: post #29

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

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

Re: Evo: Version control that works the way you think

#32

Post by user3939382 »

kajika91 wrote: post #31
voidfunc wrote: post #29

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

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/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…

Maybe someone could politely explain it to him then instead of the condescending, alienating snark for which the computing community is infamous.

Re: Evo: Version control that works the way you think

#33

Post by cies »

voidfunc wrote: post #29

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

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

Re: Evo: Version control that works the way you think

#34

Post by kajika91 »

cies wrote: post #33
voidfunc wrote: post #29

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

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://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…

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.

Re: Evo: Version control that works the way you think

#36

Post by JTyQZSnP3cQGa8B »

kajika91 wrote: post #31
voidfunc wrote: post #29

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

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/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…

He made a fix in 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.

Re: Evo: Version control that works the way you think

#37

Post by baq »

kajika91 wrote: post #34
cies wrote: post #33

Earlier quoted context omitted.

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://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…

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.

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

Re: Evo: Version control that works the way you think

#38

Post by teo_zero »

CGamesPlay wrote: post #27
teo_zero wrote: post #24

From a cursory read of the readme and design documents, it looks to me the key point about Evo is a different use of existing concepts, like branches, merges, etc. rather than new concepts. I guess if you want ephemeral branches, nobody stops you from using git in that way, too. A wrapper around git would solve the remaining propositions, that is a better command syntax. I struggled to understand git until I tried "g…

I was intrigued but... What does this even mean? "switching to another branch" is the same thing as "checking out the active commit of that branch" in git. > For example, switching to another branch automatically checks out the active commit of that branch. This is what you want most of the time: you don't switch branch and then don't even look at the code in that branch, do you?

You are right. What gitless does differently is it saves (git stash) the uncommitted files before switching: branches are well isolated, it doesn't let uncommited files be "copied over", if you understand what I mean.

Re: Evo: Version control that works the way you think

#39

Post by marssaxman »

ltbarcly3 wrote: post #35

Git works the way I think it does, because I bothered to learn how it works. Be like me, learn how things work.

We don't expect people to learn how a piece table, line array, rope, or gap buffer work in order to use a text editor built around one. If you had to understand some editor's core data structure in order to use it effectively, we'd say that editor had a terrible UI and warn people away from it.

We don't expect people to learn what a VFS is and how it works before plugging in a thumb drive. If some OS expected its users to master such arcana as a matter of course, we'd think of it as a mere curiosity - not suitable for practical use.

You don't have to know how HTTP or HTML work to use a browser. You can just click on things, and that's OK! If some browser made you learn what the DOM is and how to manipulate it before letting you into google.com, wouldn't we say "that browser is crap"?

Only git receives this special pleading: "its interface isn't terrible! You just have to learn all about how its internal implementation works, and then you will be able to use it effectively" - as though that isn't just a description of what a terrible interface is.

Re: Evo: Version control that works the way you think

#40

Post by cryptonector »

remram wrote: post #23
cryptonector wrote: post #12

Earlier quoted context omitted.

IMO managing revisions makes more sense than managing patches. Yes yes, I know about commutative patches and all that, and no I don't need that. I do reorder patches sometimes, and when they yield the same tree that's interesting, but not that interesting.

You need both. Even with Git (a snapshot-based system), some commands take a hash as a revision and some take a hash as a change (e.g. checkout/rebase/reset/bisect vs cherry-pick/revert/amend). You'll hear both in common parlance too ("this commit doesn't pass tests"/"this commit is deployed"/"rebase onto this commit" vs "I did the last commit"/"this commit is too big"/"that commit broke X"). You really have to think…

I only think of commit hashes. Branches and tags and any refs are just names for commit hashes.
Post reply on HN