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

501–510 of 717 posts

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

#501

Post by 1718627440 »

InitialLastName wrote: post #451
packetlost wrote: post #138

Earlier quoted context omitted.

I feel like submodules could be a lot easier to work with if the git command made it easy to update all submodules in one go based on branch head for the submodule.

That and a way to recursively commit/push (i.e. make a change within a submodule, commit in one step with the same message in the parent submodule). Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to: 1. Change the file 2. Commit within the submodule 3. Push the submodule 4. add the submodule change in the outer repo 5. commit in the outer r…

You can combine the push step. A submodule intentionally follows a different development/commit/version cycle, otherwise you are supposed to use a subtree.

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

#502

Post by 1718627440 »

charcircuit wrote: post #364
hhsecurity wrote: post #344

Earlier quoted context omitted.

My teaspoons are terrible at peeling potatoes. Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control. I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.

>Thats not what its for. This is a weak argument you could use for any missing feature.

But it's more like a fundamental design choice.

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

#503

Post by 1718627440 »

WorldMaker wrote: post #334
IshKebab wrote: post #301

Earlier quoted context omitted.

> this is not intended to compete with Git for general software development. This is a competitor with Perforce for game development. Well, it is intended to compete with Git for version control. It's just that Git happens to be so bad at some aspects of version control that it isn't used much in those cases. There's no good reason that Git couldn't be good at versioning binary files, or splitting up large projects.…

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.

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

#504

Post by yallpendantools »

wtetzner wrote: post #347
Melatonic wrote: post #326

Earlier quoted context omitted.

That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering. Does Gitlab do better with this?

I guess it's because git wasn't developed as enterprise software.

This. People forget a lot of Git's design philosophy harks back to the ethos of open source development. Enterprise features have made it in over the years but still mostly with the FOSS development workflow/model in mind. Also why the most enterprise-y of features (like LFS) are add-ons rather than core.

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

#505

Post by 1718627440 »

e40 wrote: post #43
niek_pas wrote: post #22

Just today as I pushed some changes to Github, I was thinking how user-unfriendly Git's UI is: Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 10 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 290 bytes | 290.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0), pack-reused 0 remote: Resolving deltas: 100% (2/2), completed with 2 local obje…

I think we can all agree that information should be behind a -v CLA. It's probably just something no one has thought of doing. I've learned over the decades to just ignore it.

I do want a progress indicator for something that might take a while without asking. If you clone things locally, Git only reports that it cloned something.

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

#506

Post by yallpendantools »

Melatonic wrote: post #326
LugosFergus wrote: post #62

Earlier quoted context omitted.

Something else that git isn't good at: permissions. In gamedev, you might have proprietary work that you want to restrict to certain users. In P4, you can add restrictions to certain directories for only those who have signed the required NDAs. That's not something that you can do in git: it's all or nothing. Maybe you can set something up with submodules, but that's going to upend your repository if you hadn't plann…

That always seemed crazy to me about git. Permissions are a pretty basic enterprise offering. Does Gitlab do better with this?

> Does Gitlab do better with this?

Not exactly but if you're not obsessed with maintaining a monorepo, Gitlab allows you to organize your repos around organizations, which then has granular permissions. The underlying primitives is still Git, of course, so you can just submodule as necessary.

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

#507

Post by runevault »

noopprod wrote: post #144

Kind of funny that it's on GitHub no hate. Missed opportunity for Lorehub.

Not really. Lore is for gamedev at companies and so not a distributed VCS. Using it for an open source project if you allow outside PRs makes no sense.

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

#508

Post by forrestthewoods »

PaulDavisThe1st wrote: post #443
LinearIO wrote: post #219

Earlier quoted context omitted.

P4 is also really well integrated into IDEs and UE Editor so that I don't need to think about it as much as I need, compared to Git. Locking assets, releasing them, merging into streams etc., is overall pretty streamlined. When it works, it's great, but when it doesn't work though, it's pretty hard to diagnose issues.

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 "merging into streams" equivalent.

Weird take. Streams is Perforce's mediocre take on Git branches. P4 stream merge is close enough to Git branch merge that I would say they're in the same family.

> P4 struck me as "what a for-profit corporation would imagine a VCS should be like, if they'd never seen git".

And yet Git has almost zero mind share in gamedev because it doesn't solve the problem.

P4 is somewhat mediocre. And it's made zero improvement in ~8 years since getting bought up by PE.

But I can also teach a game designer or artist who has never heard of source control how to correctly and safely use P4 in about 15 minutes. Meanwhile you can tell Git is badly designed because there are 10,000+ tutorials explaining how easy it is! Spoiler: things that are actually easy do not need 10,000 tutorials telling you that it is easy.

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

#509

Post by LugosFergus »

Grayskull wrote: post #491
LugosFergus wrote: post #448

Earlier quoted context omitted.

Does it actually restrict read access to specific directories? Unless I missed it, I didn't see anything in the docs about that.

"write access controlled at the branch/tag/file/directory level, including who can rewind, create, and delete branches/tags."[1] [1] https://gitolite.com/gitolite/overview.html#what-is-gitolite

I said read access. The point is that there’s restricted information that only some can access.

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

#510

Post by apatheticonion »

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.
Post reply on HN