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.
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. "
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.
I'm definitely interested in the promise here. But it seems very early days.
I'm sceptical about the whole "make a workspace for a feature, then code, then merge" workflow. For me in practice work often doesn't follow that linear path, I don't really know what feature will be finished and ready for committing until done.
One very surprising thing I have learnt about git is that it is intuitive for some people. Whereas maybe half of its users, including me, will never really get it, even after decades of use. So I am also skeptical about broad claims of intuitiveness.
I think the problem of creating a truly user friendly distributed version control system CLI is enormously challenging and requires a lot of deep thought if it is going to meet the needs of a wide range of software development practices. Looking at the DESIGN.md does not convince me they have gone deep enough in that analysis. It has a bit of a blase "it's just common sense that it should work like this!" and I'm pretty certain it's not so easy.
I think they may be too quickly assuming that there's never a need for long-lived branches. For example, for any company (like mine) that does on-prem deployments, we need to support old versions for an extended period of time by backporting security and bug fixes. This is naturally supported in git by creating a branch for each release, and I'd be curious how evo is thinking about that problem.
> Yeah. I do wish git added multiple named stages to keep this sort of thing a lot more organized.
You mean commits? You know that you can easily edit, reorder, squash, split, rename and reorganize them into separate branches before you push them anywhere, right?
No I don't mean commits. The UX is different and it would be really cumbersome to try to split work in progress code.
What would be the suggested solution? Make two empty commits and the cherry pick change chunks into each? Then to shelve/stash a change you need to make a new branch and cherry pick back? Sounds really cumbersome compared to the current staging workflow.
Making many wip commits with small chunks and then squashing and/or splitting them into proper sharable commits once I'm done is my usual mode of operation whenever a single staging area is not enough for what I'm working on. `git rebase -i` makes it a breeze. I'm trying to imagine what multiple named staging areas would bring into the picture there that isn't already provided by commits and I struggle.
If you think that's easier or just as easy as adding an id to the staging commands then I guess its meaningless to you. I think it can be made much easier than what's possible now and I think there's value in fleshing out the part of git that this is actually about, ie staging incomplete commits.
If its actually single commit, auto-squashed branches behind the scenes, that's fine.
Cute, but just use jj. It has all the features evo promises (plus undo and first-class conflicts) but is robust, refined, and ready to use today. Structural merges sound like an anti-feature.
This appears to either be a wrapper around an incomplete minimal subset of git commands (with git-lfs also included) focused only on the standard feature-branch trunk-based development workflow, or an unecessary rewrite of an inciplete subset. Either way, the semantics are identical, and most of the command are identical (except when some are renamed unnecessarily).
This is missing most of the necessary commands for when you collaborate, e.g. my remote has changes I don't have, but I also have changes it doesn't have, and the two conflict. Or to bring your feature branch ("workspace") up to date relative to the target branch so you can publish the difference for someone to review. Merge/Rebase up to date relative to a target branch is often non-trivial in real world scenarios and is part of what a code review expects to cover.
The "headline"(?) feature seems to be structural merging of JSON and YAML, which is a lesser version of semantic merging that other tools for use with git already provide.
Darcs was probably the most interesting VCS in this space. It made a lot more sense because it was more about managing patches (or features) instead of history that we do now with git.
IIRC Darcs had a lot of momentum with it until there was a problem discovered with it's algebra that allowed itself to go into an infinite loop. And then it died.
At least with git, I can think in terms of DAGs which should be in the knowledge of any serious senior software engineer.
I don't know if managing patches makes more sense than managing revisions. The truth is that you need both.
Sometimes you are authoring patches, and reviewing patches. But sometimes you are releasing/trying/building revisions, and you are releasing revisions.
Moving to the dual representation fixes some issues and brings its own. I think the only reason why some people think it is better is because they haven't used it long enough to get frustrated by the new issues, the way they had time to be frustrated by the old dual issues.
Managing patches or features seems to be easier to think about: "I want feature X in this build but not Y for reasons even though Y was in the last build..."
But language (software or otherwise) doesn't really work that way.
You could imagine a novel written using a VCS where in one branch of the novel a main character lives throughout the novel dying at the end. In another branch, that character dies in chapter 1. Now try to merge the two branches automatically.
Sure, you might get a novel, but the character lives on after chapter 2 nonsensically.
That's the same issue with programming languages. "Syntax" is not the same as "Functionally Coherent".
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 of commits as both, neither view is entirely sufficient.
> A commit hash identifies both a patch or a revision, that's my point.
Strictly speaking, no. A commit hash identifies a tree. There is no patch stored, nor is a patch bound into the commit hash in any way. The patch is indirectly implied as the differences between the new commit's tree hash and the preceding commit's tree hash.
For people looking at Darcs, Pijul[0] is an interesting advancement in the space, as it solves the exponential merge time problem that can make Darcs intractable.
Sadly Pijul also doesn't have the consistent maintenance one would like to see from a daily-driver VCS.
It would help a lot to post a video or gif, showing how it deals with 3 features being merged with a lot of conflicts. It really has potential to be awesome, but you gotta show how.
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 "gitless"[1], a wrapper around git that lets you focus on your workflow ignoring git's own weirdness. 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?
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.
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.
This is not true at all, and your examples are bad.
You don't need to know how btree's work to use SQL, true, but you need to know they exist and how they can be used by the database.
You don't know how to rebuild an engine to use a car, but you need to know what to put in the gas tank, when to change the oil, when to change the tires, what tires you can buy, how much air goes in them. You have to know a lot about how a car works to operate a car, or you have to pay someone to figure it out for you every time something needs done.
Git is the same. You have to know about how it works, not all the details of how it works. You could hire someone to do everything in git for you like you probably do with a car, but Git isn't a tool for stupid babies, it's a tool for professionals, and frankly professionals should know how their professional tools work.
If you can't be bothered or struggle to understand how your tools work as a professional, you should change professions as you are incompetent. If you think it's better if you don't have to know, then you will be passed by like you are standing still in your career by people who don't have qualms about knowing how things work and therefore can solve lots of problems in a couple minutes you think are too icky to bother to understand and would take you weeks.
(Note: I'm saying 'you' but I'm not addressing anyone in particular with that, so please don't take this as some kind of personal attack.)
How does "bringing 2 copies into 1" (aka merge) work?
For big media files, lock / last timestamp is OK.
...but is there anything that helps merge changes in text? Not saying lock/timestamp for *everything* is bad, but IMHO, intelligent auto-merge of text is a main reason git is good.
https://www.reddit.com/r/golang/comments/1i6v9ou/evo_a_new_v...