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

Lore – Open source version control system designed for scalability

lore.org

Post reply on HN
Print view View original

521–530 of 717 posts

Re: Lore – Open source version control system designed for scalability

#521

Post by WorldMaker »

IshKebab wrote: post #476
WorldMaker wrote: post #334

Earlier quoted context omitted.

It feels like a Pareto Principle problem. 80% of source control is text files that can be three-way merged as text files, but a lot of hard problems are in that 20% that isn't. Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case. But yeah, so many of those extra tools in that 80 to 90% area are awful…

I would say that at least the submodule problem is more like the last 45%. Every single company I've worked in has ended up using submodules and it always ends up causing huge amounts of pain because they suck. The only alternative Git offers, which is slightly better IMO, is monorepos. But they're only slightly better - they also have really significant downsides. I'm 100% sure there's a much nicer solution to the k…

From my viewpoint, a lot of the submodule problems are effectively same as the monorepo problems, including how you end up with both problems. There certainly are factorings of projects into "microservices" and moving the dependency management problems out of source control to package managers of different types. Microservices and package management sure do have their own problems and trade-offs and there isn't a "universal solution", just what side of the trade-offs you prefer to be on.

Re: Lore – Open source version control system designed for scalability

#522

Post by therealpygon »

ifh-hn wrote: post #252
danudey wrote: post #195

Earlier quoted context omitted.

As others have said, it's Apple and they do not take kindly to other people leaking their technology/announcements ahead of time. See also: the time that ATI's CEO told his employees that their chips would be powering Apple's to-be-announced hardware a few days before the announcement. Steve Jobs responded by pulling all of ATI's hardware from its demo units at the announcement, not mentioning ATI at all, cancelling…

Sounds like a bit of a dick...

For violating an embargo and publishing a press release announcing products of another company that hadn’t been debuted? What “non-dick” response do you think is appropriate against a prospective partner that violated clear guidelines that defined their partnership which basically included “#1: Keep your mouth shut”, exactly?

Re: Lore – Open source version control system designed for scalability

#523

Post by PaulDavisThe1st »

forrestthewoods wrote: post #508
PaulDavisThe1st wrote: post #443

Earlier quoted context omitted.

One of the many points of git's design is that most of the steps you need to do in P4 are not necessary at all. You do not "lock assets", you do not "release them", there is no "merging into streams" equivalent. The entire workflow with git avoids huge amounts of the cognitive load of using P4, which in turn means that integration with IDEs becomes much less important. I worked with P4 around the time I first started…

> You do not "lock assets", Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it". Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets. > there is no "m…

> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.

OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML).

I didn't realize that LinearIO's comment was really that specific; it appeared to be describing general properties of P4 unrelated to the binary issue.

The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.

I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.

Re: Lore – Open source version control system designed for scalability

#524

Post by WorldMaker »

1718627440 wrote: post #503
WorldMaker wrote: post #334

Earlier quoted context omitted.

It feels like a Pareto Principle problem. 80% of source control is text files that can be three-way merged as text files, but a lot of hard problems are in that 20% that isn't. Git does very well at the 80% and with tools like custom merge tools and git lfs/annex and git sparse "cone" checkouts can get pretty close to hitting the 90 or 95% case. But yeah, so many of those extra tools in that 80 to 90% area are awful…

That it is difficult to merge e.g. media files has nothing to do with Git. It's just that it is one of the core assumptions in Git, that it is fine to diverge locally and cheaply, because you can just merge. I think this can't really be solved without a centralized server and that is just something, that Git doesn't want to be.

Yeah, decentralization is an important principle to git and tools to manage concurrency such as "file locking" become a lot harder to do in an a decentralized way than a centralized one. (Pijul has the same problems because decentralization is also an important principle to it.) It is something of a problem space that transcends beyond git. But I also think this is how we've arrived to this moment where the best source control tools have decentralization as an important principle. That 80% case with easy mergeable text files is a lot nicer to work with in a decentralized world because it is "offline-first" and quite capable. It often seems, across a lot of different styles of software development, worth the trade-offs that things like media files are harder to work with. (Again, realizing the obvious problems with game development where that often flips and the majority of work is often in the media file assets as much or more than the text files.)

Re: Lore – Open source version control system designed for scalability

#525

Post by SCLeo »

zephen wrote: post #336
orthoxerox wrote: post #293

Earlier quoted context omitted.

Git submodules are the regular expressions of version control.

When you use regular expressions, you now have two problems. When you use git submodules, you now have five or six problems.

And every PR turns into a triple recursive reverse merge.

Re: Lore – Open source version control system designed for scalability

#526

Post by woctordho »

throw2ih020 wrote: post #24

For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to o…

It's 2026. Historically the way for large binaries in git was git LFS. Now the way for large binaries in git is just git.

Re: Lore – Open source version control system designed for scalability

#527

Post by maccard »

PaulDavisThe1st wrote: post #523
forrestthewoods wrote: post #508

Earlier quoted context omitted.

> You do not "lock assets", Uhhhhhh. Locking binary assets is ABSOLUTELY NECESSARY in Git. Except Git can't actually do that. So what locking binary assets Git looks like in practice is an unenforced message in Slack saying "hey I'm changing this file please no one else touch it". Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets. > there is no "m…

> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets. OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML). I didn't realize that LinearIO's comment was really that specific; it appeared to…

> The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.

It's "hard to say" if you want to ignore the fact that it requires 10k tutorials. Meanwhile, there are 500+ person companies with non technical users using P4 with literally 0 onboarding other than "by the way, undo is broken don't use it".

> I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.

Using P4 is: Download P4V, install plugin for $EDITOR, and double click on a changelist to submit.

Re: Lore – Open source version control system designed for scalability

#528

Post by maccard »

reactordev wrote: post #385
computerdork wrote: post #348

Earlier quoted context omitted.

Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.

check-in isn’t a concept in git because there is no server in git. It’s just a log. The beauty of the merkle tree. It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source. Delta patches become effortless

> It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.

If everyone uses it wrong, it was designed wrong. See Q-tips.

Re: Lore – Open source version control system designed for scalability

#529

Post by woctordho »

apatheticonion wrote: post #510
throw2ih020 wrote: post #24

For context, since a lot of people on HN haven't worked on games - this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Git is fine for text based files like code, but it's really bad at stuff like textures, 3D models, audio files, and other non-text files that game developers need to collaborate on. For example, one artist might need to o…

Another thing git isn't good at is massive codebases with long histories. IMO git should have a configuration option to pull commits lazily without the need for `--depth` and the `git fetch` dance that goes along with it.

There's `--filter=blob:none` and it allows to automatically fetch blobs when needed.

Re: Lore – Open source version control system designed for scalability

#530

Post by apatheticonion »

woctordho wrote: post #529
apatheticonion wrote: post #510

Earlier quoted context omitted.

Another thing git isn't good at is massive codebases with long histories. IMO git should have a configuration option to pull commits lazily without the need for `--depth` and the `git fetch` dance that goes along with it.

There's `--filter=blob:none` and it allows to automatically fetch blobs when needed.

I wish it was as simple as `git clone --lazy`

I had previously worked on a big tech monorepo that has gigabytes of history. It would take forever to clone or do operations on. I had a cheat sheet of git commands that would do things lazily but I forget them (which is the issue).

Post reply on HN