Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The future of version control

bramcohen.com

Post reply on HN
Print view View original

181–190 of 407 posts

Re: The future of version control

#181

Post by procaryote »

mikey-k wrote: post #10

Interesting idea. While conflicts can be improved, I personally don't see it as a critical challenge with VCS. What I do think is the critical challenge (particularly with Git) is scalability. Size of repository & rate of change of repositories are starting to push limits of git, and I think this needs revisited across the server, client & wire protocols. What exactly, I don't know. :). But I do know that in my curre…

What kind of scalability issues have you had with git?

Is it because of a monorepo?

Re: The future of version control

#182

Post by throwaway7783 »

IgorPartola wrote: post #127
clktmr wrote: post #121

Earlier quoted context omitted.

The thing is, you'll typically switch to master to merge your own branch. This makes your own branch 'theirs', which is where the confusion comes from.

Not me. I typically merge main onto a feature branch where all the conflicts are resolved in a sane way. Then I checkout main and merge the feature branch into it with no conflicts. As a bonus I can then also merge the feature branch into main as a squash commit, ditching the history of a feature branch for one large commit that implements the feature. There is no point in having half implemented and/or buggy commits…

Yep. This is the only model that has worked well for me for more than a decade.

Re: The future of version control

#183

Post by mweidner »

mentalgear wrote: post #35

> [CRDT] This means merges don’t need to find a common ancestor or traverse the DAG. Two states go in, one state comes out, and it’s always correct. Well, isn't that what the CRDT does in its own data structure ? Also keep in mind that syntactic correctness doesn't mean functional correctness.

You can think of the semantics (i.e., specification) of any CRDT as a function that inputs the operation history DAG and outputs the resulting user-facing state. However, algorithms and implementations usually have a more programmatic description, like "here is a function `(internal state, new operation) -> new internal state`", both for efficiency (update speed; storing less info than the full history) and because DAGs are hard to reason about. But you do see the function-of-history approach in the paper "Pure Operation-Based Replicated Data Types" [1].

[1] https://arxiv.org/abs/1710.04469

Re: The future of version control

#185

Post by mamcx »

kungito wrote: post #85
psychoslave wrote: post #76

Earlier quoted context omitted.

That still have an issue with the vocabulary. Things like "theirs/our" is still out of touch but it's already better than a loose spatial analogy on some representation of the DAG. Something like base, that is "common base", looks far more apt to my mind. In the same vein, endogenous/exogenous would be far more precise, or at least aligned with the concern at stake. Maybe "local/alien" might be a less pompous vocabul…

After 15 years i still cant remember which is which. I get annoyed every time. Maybe I should invest 15 minutes finally to remember properly

Seriously!

Why not show the names of the branch + short Id (and when is not direct name, at least "this is from NAME")

Re: The future of version control

#186

Post by killerstorm »

ulrikrasmussen wrote: post #19

The thing about how merges are presented seems orthogonal to how to represent history. I also hate the default in git, but that is why I just use p4merge as a merge tool and get a proper 4-pane merge tool (left, right, common base, merged result) which shows everything needed to figure out why there is a conflict and how to resolve it. I don't understand why you need to switch out the VCS to fix that issue.

Yeah, also JetBrains IDEs like IntelliJ have very nice merge UI.

Perhaps the value of doing it on SCM level is that it can remember what you did. Git has some not-so-nice edge cases.

Re: The future of version control

#187

Post by [deleted] »

ZoomZoomZoom wrote: post #4

The key insight in the third sentence? > ... CRDTs for version control, which is long overdue but hasn’t happened yet Pijul happened and it has hundreds - perhaps thousands - of hours of real expert developer's toil put in it. Not that Bram is not one of those, but the post reads like you all know what.

[deleted]

Re: The future of version control

#188

Post by Retr0id »

tbrownaw wrote: post #178
theknarf wrote: post #164

You can't use CRDTs for version control, having conflicts is the whole point of version control. Sometimes two developers will make changes that fundamentally tries to change the code in two different ways, a merge conflict then leaves it up to the developer who is merging/rebasing to make a choice about the semantics of the program they want to keep. A CRDT would just produce garbage code, its fundamentally the wron…

> You can't use CRDTs for version control You misunderstand what is being proposed. Using CRDTs to calculate the results of a merge does not require being allowed to commit the results of that calculation, and doesn't even require that you be able to physically realize the results in the files in your working copy. . Consider for example if you want to track and merge scalar values. Maybe file names if you track rena…

If semantics-layer conflicts still have to be detected somehow, and resolved by hand, what value is the underlying CRDT providing?

Re: The future of version control

#190

Post by sayrer »

simonw wrote: post #9

This thing is really short. https://github.com/bramcohen/manyana/blob/main/manyana.py is 473 lines of dependency-free Python (that file only imports difflib, itertools and inspect) and of that ~240 lines are implementation and the rest are tests.

The joke is there in the name. It is wrong (on purpose): it should be "Mañana". That term means "tomorrow" in your Spanish class, but it can mean "later/future/morning" or even "later this afternoon".

In English, you might think of "procrastination" or "we'll get to it."

In Portuguese, you would say "proxima semana", literally "next week", but it means "we'll get to it" (won't get to it).

Post reply on HN