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.
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.
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.
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.
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?
Unfortunately gitless doesn't seem maintained anymore...
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.
> evo workspace merge
wtf does that even do. I have no idea if it does what I think because I have no idea what it does.
'push' is a hundred times more clear than this obscure incantation.
Love how a competitor to git was published on GitHub
Git works the way I think it does, because I bothered to learn how it works. Be like me, learn how things work.
That sure is a reasonable-looking user interface.
LICENSE 404, though Readme says MIT.
Obligatory link to https://pijul.org/ which I’d say also fits the description - in which you really commit patches instead of whole trees.
> No more merge conflicts that make you want to quit programming.
Ctrl + W
> Large file support built-in
You've got my attention.
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.
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...