11–20 of 46 posts
> 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.
[0]: https://github.com/crazywolf132/evo/blob/main/docs/migration...
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…
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'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. Wherea…
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.
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…
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. Wherea…
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. Wherea…
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.
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.
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.
Ctrl + W
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. Wherea…
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.
git rebase --update-refs