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

101–110 of 407 posts

Re: The future of version control

#101

Post by AceJohnny2 »

vova_hn2 wrote: post #63
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.

I have a weird hobby: about once a year I go to the theory page [0] in pijul manual and see if they have fixed the TeX formatting yet. You would think that if a better, more sound model of storing patches is your whole selling point , you would want to make as easy as possible for people who are interested in the project to actually understand it. It is really weird not to care about the first impression that your ma…

> It is really weird not to care about the first impression that your manual makes on a curious reader.

On the contrary, I think this is an all-too-familiar pitfall for the, er... technically minded.

"I've implemented it in the code. My work here is done. The rest is window dressing."

Re: The future of version control

#102

Post by devnotes77 »

afiori wrote: post #100
kungito wrote: post #85

Earlier quoted context omitted.

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

iirc ours is always the commit the merge is starting from. the issue is that with a merge your current commit is the merging commit while with a rebase it is reversed. I suspect that this could be because the rebase command is implemented as a serie of merges/cherry-picks from the target branch.

[dead]

Re: The future of version control

#103

Post by gnarlouse »

tasuki wrote: post #93
gnarlouse wrote: post #14

I think something like this needs to be born out of analysis of gradations of scales of teams using version control systems. - What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts? - What do teams of 1, 10, 100, 1k, etc care the most about? - How does the modern "agent explosion" potentially affect this? For example, my experience working in the 1-100…

> What kind of problems do 1 person, 10 person, 100 person, 1k (etc) teams really run into with managing merge conflicts? > What do teams of 1, 10, 100, 1k, etc care the most about? Oh god no! That would be about the worst way to do it. Just make it conceptually sound.

Probably, but just introducing CRDTs also feels like the wrong way to approach the problem! :)

Re: The future of version control

#104

Post by aduwah »

alunchbox wrote: post #36

Jujutsu honestly is the future IMO, it already does what you have outlined but solved in a different way with merges, it'll let you merge but outline you have conflicts that need to be resolved for instance. It's been amazing watching it grow over the last few years.

The only reason I have not defaulted to jj already is the inability to be messy with it. Easy to make mistakes without "git add"

Re: The future of version control

#105

Post by gojomo »

skydhash wrote: post #48
gojomo wrote: post #27

Earlier quoted context omitted.

Should you be counting on confusion of an underpowered text-merge to catch such problems? It'll fire on merge issues that aren't code problems under a smarter merge, while also missing all the things that merge OK but introduce deeper issues. Post-merge syntax checks are better for that purpose. And imminently: agent-based sanity-checks of preserved intent – operating on a logically-whole result file, without merge-t…

> It'll fire on merge issues that aren't code problems under a smarter merge, while also missing all the things that merge OK but introduce deeper issues. That has not been my experience at all. The changes you introduced is your responsibility. If you synchronizes your working tree to the source of truth, you need to evaluate your patch again whether it introduces conflict or not. In this case a conflict is a nice s…

If you're relying on a serialized 'source of truth', against which everyone must independently ensure their changes sanely apply in isolation, the. you've already resigned yourself to a single-threaded process that's slower than what improved merges aim to enable.

Sure, that works – like having one (rare, expensive) savant engineer apply & review everything in a linear canonical order. But that's not as competitive & scalable as flows more tolerant of many independent coders/agents.

Re: The future of version control

#106

Post by vessenes »

63stack wrote: post #99
gavinhoward wrote: post #87

Bram Cohen is awesome, but this feels a little bare. I've put much more thought into version control ([1]), including the use of CRDTs (search for "# History Model" and read through the "Implementing CRDTs" section). [1]: https://gavinhoward.com/uploads/designs/yore.md

Is this the Bram Cohen who made bittorrent? There is surprisingly little information on this page.

Yes

Re: The future of version control

#107

Post by catlifeonmars »

Can we stop using line-oriented diffs in favor of AST-oriented diffs?

Is it just lack of tooling, or is there something fundamentally better about line-oriented diffs that I’m missing? For the purpose of this question I’m considering line-oriented as a special case of AST-oriented where the AST is a list of lines (anticipating the response of how not all changes are syntactically meaningful or correct).

Re: The future of version control

#108

Post by fn-mote »

bob1029 wrote: post #79

I think there are still strong advantages to the centralized locking style of collaboration. The challenge is that it seems to work best in a setting where everyone is in the same physical location while they are working. You can break a lock in 30 seconds with your voice. Locking across time zones and date lines is a nonstarter by comparison.

It seems like in a reasonable sized org you should not be merging so often that “centralized locking … across time zones” should be an issue.

Are people really merging that often? What is being merged? Doc fixes?

Re: The future of version control

#109

Post by marcellus23 »

IgorPartola wrote: post #97
kungito wrote: post #85

Earlier quoted context omitted.

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

Let’s see if I get this wrong after 25 years of git: ours means what is in my local codebase. theirs means what is being merged into my local codebase. I find it best to avoid merge conflicts than to try to resolve them. Strategies that keep branches short lived and frequently merging main into them helps a lot.

That's kind of the simplest case, though, where "theirs" and "ours" makes obvious sense.

What if I'm rebasing a branch onto another? Is "ours" the branch being rebased, or the other one? Or if I'm applying a stash?

Re: The future of version control

#110

Post by cxr »

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.

> I don't understand why you need to switch out the VCS to fix that issue.

For some reason, when it comes to this subject, most people don't think about the problem as much as they think they've thought about it.

I recently listened to an episode on a well-liked and respected podcast featuring a guest there to talk about version control systems—including their own new one they were there to promote—and what factors make their industry different from other subfields of software development, and why a new approach to version control was needed. They came across as thoughtful but exasperated with the status quo and brought up issues worthy of consideration while mostly sticking to high-level claims. But after something like a half hour or 45 minutes into the episode, as they were preparing to descend from the high level and get into the nitty gritty of their new VCS, they made an offhand comment contrasting its abilities with Git's, referencing Git's approach/design wrt how it "stores diffs" between revisions of a file. I was bowled over.

For someone to be in that position and not have done even a cursory amount of research before embarking on a months (years) long project to design, implement, and then go on the talk circuit to present their VCS really highlighted that the familiar strain of NIH is still alive, even in the current era where it's become a norm for people to be downright resistant to writing a couple dozen lines of code themselves if there is no existing package to import from NPM/Cargo/PyPI/whatever that purports to solve the problem.

Post reply on HN