_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
URI Visit Hacker News on the Web
COMMENT PAGE FOR:
URI Evo: Version control that works the way you think
refulgentis wrote 1 hour 5 min ago:
> No more merge conflicts that make you want to quit programming.
Ctrl + W
dcre wrote 1 hour 15 min ago:
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.
URI [1]: https://github.com/jj-vcs/jj
aaravchen wrote 1 hour 17 min ago:
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.
stevage wrote 2 hours 33 min ago:
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.
necubi wrote 1 hour 28 min ago:
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.
BobbyTables2 wrote 1 hour 56 min ago:
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.
davvid wrote 1 hour 0 min ago:
These are called stacked branches in git. You're possibly looking
for:
git rebase --update-refs
... or a GUI like Git Cola that does this for you by default.
jayd16 wrote 1 hour 24 min ago:
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.
seba_dos1 wrote 59 min ago:
> 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?
remram wrote 2 hours 45 min ago:
> 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.
blondin wrote 2 hours 18 min ago:
"evo workspace merge" maps[0] to "git merge"
[0]:
URI [1]: https://github.com/crazywolf132/evo/blob/main/docs/migration...
amtamt wrote 2 hours 46 min ago:
LICENSE 404, though Readme says MIT.
marssaxman wrote 3 hours 17 min ago:
That sure is a reasonable-looking user interface.
bb88 wrote 3 hours 19 min ago:
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.
hboon wrote 1 hour 47 min ago:
Darcs was also very very slow when I used it.
remram wrote 2 hours 47 min ago:
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.
cryptonector wrote 2 hours 6 min ago:
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.
remram wrote 7 min ago:
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.
bb88 wrote 2 hours 23 min ago:
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 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".
pedrorissato wrote 4 hours 34 min ago:
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.
geenat wrote 4 hours 42 min ago:
> 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.
DIR <- back to front page