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

361–370 of 407 posts

Re: The future of version control

#361

Post by samuelstros »

jayd16 wrote: post #355
samuelstros wrote: post #91

Earlier quoted context omitted.

Improving on "git not handling non-text files" is a semantic understanding aka parse step in between the file write. Take a docx, write the file, parse it into entities e.g. paragraph, table, etc. and track changes on those entities instead of the binary blob. You can apply the same logic to files used in game development. The hard part is making this fast enough. But I am working on this with lix [0]. [0] https://gi…

What's the plan for large files that can't be merged? Images, executable binaries, encrypted files, that sort of thing?

Simple left or right merge. One overwrites the other one.

The appeal or structured file formats like .docx, .json, etc. Images are unstructured and simple "do you want to keep the left or right image" is good enough.

Re: The future of version control

#362

Post by ghusbands »

hn_throwaway_99 wrote: post #203
cxr wrote: post #110

Earlier quoted context omitted.

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

> 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. It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a co…

A common misconception is that git works with diffs as a primary representation of patches, and that's the implied reading of "stores diffs". Yes, git uses diffs as an optimisation for storage but the underlying model is always that of storing whole trees (DAGs of trees, even), so someone talking about it storing diffs is missing something fundamental. Even renames are rederived regularly and not stored as such.

However, context would matter and wasn't provided - without it, we're just guessing.

Re: The future of version control

#363

Post by philwelch »

Nursie wrote: post #279
philwelch wrote: post #205

Regardless of the merits of CRDT's, I'm just glad someone is finally trying to create a new version control system. Everyone loves to complain about Git but nobody's actually tried to move beyond it in two decades.

There are those of us who remember the before-times, who I think are in general just happy we have git. Having lived through sccs, pvcs, SourceSafe, Clearcase and svn (among others), the introduction of lightweight, sane branching, merging, rebasing etc was a revelation. Yes, there are still things that an adept could do with some of those other systems that git doesn't make easy. For example we have the holy war bet…

I can definitely relate to that, and I'm actually quite fond of git myself. I just never expected that people would stop trying to make a better version control system. That's not entirely fair, a lot of work has been invested in Pijul and Fossil, but I would have expected much more interest in alternatives. I remember all of the reasons Git was so new and exciting at the time, but now it feels like we're all locked into it, not out of any deliberate attempt at vendor lockin but out of complacency, and because fewer and fewer of us still remember a time that it felt possible to invent a better version control system.

Re: The future of version control

#364

Post by theK »

furyofantares wrote: post #357
theK wrote: post #286

Earlier quoted context omitted.

Isnt that a bit dangerous in its own? If the merge process can complete without conflicts being resolved, doesnt it just push the Problem down the road? All of a sudden you have to deal with failing CI or ghost features that involve multiple people where actually you just should has solved you conflict locally at merge time.

The tooling can force resolution at any step desired.

What's the point of options when there only is one correct answer?

Re: The future of version control

#365

Post by tinfoilcondom »

Why are some projects like “artifact” marked Dead here while others like “fossil” are promoted in the comments?

What counts as advertise vs spam? They seem like nearly identical posts and both projects really exist, separate authors.

Why are random posts marked Dead on this platform? Seems like outright censorship

Re: The future of version control

#367

Post by cweagans »

itsnexis wrote: post #366

[flagged]

> it makes history a lie that eventually collapses under its own weight in large teams

Can you please elaborate on this? I've seen this argument from others as well, but nobody has ever been able to articulate what that actually looks like and why rebasing branches specifically is to blame.

My perspective: whatever happens to the commit history on your non-`main` branch is your business. I don't care about the specifics until your work is merged into a shared branch that we all understand to be the canonical representation of the software we're working on.

Re: The future of version control

#369

Post by cxr »

hn_throwaway_99 wrote: post #203
cxr wrote: post #110

Earlier quoted context omitted.

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

> 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. It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why. I understand how commit snapshots and packfiles work, and the way delta compression works in packfiles might lead me to calling it "storing diffs" in a co…

> It seems like you have taken offense to the phrase "stores diffs", but I'm not sure why.

Yeah, I'm not sure why it seems that way to you, either.

> the way delta compression works in packfiles might lead me to calling it "storing diffs" in a colloquial setting

We're not discussing some fragment of some historical artifact, one part of a larger manuscript that has been lost or destroyed, with us left at best trying to guess what they meant based on the little that we do have, which amounts to nothing more than the words that you're focusing on here.

Their remarks were situated within a context, and they went on to speak for another hour and a half about the topic. The fullness of that context—which was the basis of my decision to comment—involved that person's very real and very evident overriding familiarity with non-DVCS systems that predate Git and that familiarity being treated as a substitute for being knowledgeable about how Git itself works when discussing it in a conversation about the tradeoffs that different version control systems force you to make.

Post reply on HN