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

21–30 of 46 posts

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

#21

Post by seba_dos1 »

jayd16 wrote: post #16
BobbyTables2 wrote: post #13

Earlier quoted context omitted.

I’m skeptical of anything that assumes a single branch/workspace per feature. My career never has worked that way. I’m always juggling a series of changes that will be reviewed and merged in close succession but separately. I keep everything in a single branch and have scripts to cherry pick revisions for merge requests.

Yeah. I do wish git added multiple named stages to keep this sort of thing a lot more organized. Perforce can have multiple active CLs but they can only hold changes at the file level instead of hunks. That ends up even more maddening somehow.

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

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

#22

Post by [deleted] »

bb88 wrote: post #10
remram wrote: post #6

Earlier quoted context omitted.

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…

I don't know either. 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…

[deleted]

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

#23

Post by remram »

cryptonector wrote: post #12
remram wrote: post #6

Earlier quoted context omitted.

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…

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.

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

#24

Post by teo_zero »

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

[1] https://github.com/gitless-vcs/gitless

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

#27

Post by CGamesPlay »

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?

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

#28

Post by xearl »

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…

> For example, switching to another branch automatically checks out the active commit of that branch.

    git switch $BRANCH

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

#30

Post by hobofan »

bb88 wrote: post #4

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

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.

[0]: https://pijul.org/manual/why_pijul.html

Post reply on HN