I’m not defending, or even interested in, evo, just pointing out that the getting-started.md doesn’t seem to be a good doc to see how it differs from git.
Reading through the design doc, it appears that this borrows the same primitives from git: commits, trees, blobs, refs. Is there anything it does differently regarding the “building blocks” of the system?
After a quick read, my conclusion is that it improves by having built-in server, large file support, and key management. It also seems to be smarter when merging certain types of files. The “git streamlining” here might be useful for a bunch of folks, but I’m interested in different version control abstractions, so I’d love to get pointers to anything different this project does at this level.
I think this project would benefit from a high-level “Why evo?” page.
On the upside, I like the idea of syntax-aware merges (and diffs), since I think we leave a lot on the table by treating files with structure as just a bunch of lines. Plus, LFS by default is nice in the modern era. Ditto for a builtin push/pull server.
On the downside, I’m sad to see the concept of staging being replicated; Jujutsu’s convinced me it’s not necessary.
I really wish Pijul offered this—built-in or as an add-on. Currently without reverse engineering the Nest API & building it yourself, you cannot self-host a Pijul repository over HTTP that is compatible with the pijul clone. Darcs can work with just a static HTTP server in front of a repository, but it also doesn’t have advanced features like channels/branches or automatically generating tarballs of states.
Immediately starred. I don’t want a powerful DCVS. I want a simple one that gets out of my way. I just don’t care enough about version control tools to read books about them, you know?
But some (hopefully constructive!) feedback, after reading the README I’m left wondering “ok, so what’s the concurrency/sync model”? If it’s not truly multi-master and completely decentralized, I think it’s a no go. Git may be a mess but that’s one thing it popularised that I think is now table stakes.
You say offline first - can you be more specific? Speak dist sys to me!
I don’t want a powerful DCVS. I want a simple one that gets out of my way.
When someone says “simple”, I think of Fossil SCM. It also has a web interface built-in. You don’t even need to install it, just download the all-in-one executable.
To not regurgitate other sites too much this project is bs.
Marketet as if production/enterprise ready but hacked together in a day. Author admits it, but doesn’t change the README/description
https://www.reddit.com/r/golang/comments/1i6v9ou/evo_a_new_version_control_system_written_in_go/
this is fine https://github.com/crazywolf132/evo/blob/15d2ec6e821ef221961925e4899c545ec660fcbe/internal/core/signing.go#L98-L108
I certainly don’t think git is the be all and end all, but this workflow sounds exactly like git: https://github.com/crazywolf132/evo/blob/main/docs/getting-started.md
Which is fine! Git is popular and good, but I’d love to know what pain points this solves.
The linked README mentions some features distinguishing it from git, most of which are not about the workflow itself, from what I see.
E.g., syntax-aware merging for JSON and YAML.
Git supports custom merge algorithms. See for example https://mergiraf.org/ which you can drop into an existing repo.
Configure your git to use mergiraf as the merge tool, and you have that too (and more).
I’m not defending, or even interested in, evo, just pointing out that the getting-started.md doesn’t seem to be a good doc to see how it differs from git.
[Comment removed by author]
Reading through the design doc, it appears that this borrows the same primitives from git: commits, trees, blobs, refs. Is there anything it does differently regarding the “building blocks” of the system?
After a quick read, my conclusion is that it improves by having built-in server, large file support, and key management. It also seems to be smarter when merging certain types of files. The “git streamlining” here might be useful for a bunch of folks, but I’m interested in different version control abstractions, so I’d love to get pointers to anything different this project does at this level.
Julius vibes.
https://ploum.net/2024-12-23-julius-en.html
i must be old, I see nothing wrong with git
I think this project would benefit from a high-level “Why evo?” page.
On the upside, I like the idea of syntax-aware merges (and diffs), since I think we leave a lot on the table by treating files with structure as just a bunch of lines. Plus, LFS by default is nice in the modern era. Ditto for a builtin push/pull server.
On the downside, I’m sad to see the concept of staging being replicated; Jujutsu’s convinced me it’s not necessary.
Somehow, all the documentation on this project tastes like ChatGPT
This might be a weird criticism, but:
I’ve been struggling with a lot of descriptions of “works the way you think”. It’s usually not the way I think.
It was revealing to me when I figured that bit out after running into a wall for years.
I really wish Pijul offered this—built-in or as an add-on. Currently without reverse engineering the Nest API & building it yourself, you cannot self-host a Pijul repository over HTTP that is compatible with the
pijul clone. Darcs can work with just a static HTTP server in front of a repository, but it also doesn’t have advanced features like channels/branches or automatically generating tarballs of states.Immediately starred. I don’t want a powerful DCVS. I want a simple one that gets out of my way. I just don’t care enough about version control tools to read books about them, you know?
But some (hopefully constructive!) feedback, after reading the README I’m left wondering “ok, so what’s the concurrency/sync model”? If it’s not truly multi-master and completely decentralized, I think it’s a no go. Git may be a mess but that’s one thing it popularised that I think is now table stakes.
You say offline first - can you be more specific? Speak dist sys to me!
When someone says “simple”, I think of Fossil SCM. It also has a web interface built-in. You don’t even need to install it, just download the all-in-one executable.