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

461–470 of 717 posts

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

#461

Post by tom_ »

akurilin wrote: post #429
dijit wrote: post #384

Earlier quoted context omitted.

ditto; and UE5 on anything that isn't perforce is a lesson in pain. I just took over a team that was using Git, and yes, I know it's everyones favourite VCS but for Games it's just about the worst thing available. I could measure art reviews with git in hours, now with perforce its seconds. I wish I was joking. All the interesting tools that UE5 uses (Horde/UBA for a clean example) will require perforce. but, Perforc…

Couldn't agree more. I wonder why the company stalled as much as it did. To be fair they've been around for three decades, maybe it's just hard to keep momentum for that long, especially if you're in a dominant position with no competition coming after you.

They got sold to a private equity company in 2016.

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

#462

Post by ZekeSulastin »

isodev wrote: post #430
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…

It’s funny how exciting Apple Pay was when introduced, only Apple pulled the lock-everyone-in card and now we’re all using QRcodes.

I guess the "we" depends strongly on location - I've no problem using Apple Pay basically everywhere except Walmart.

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

#464

Post by a1o »

raincole wrote: post #283
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…

One thing I don't like about Git LFS is that there is no way to delete very old history. It's the 'git spirit' to not allow deleting history, but in the context of LFS it sounds horrible. Especially if you use Github. If there is an asset that is updated very frequently in the early stage of development, you'll be charged for all the storage for the rest of the repo's life. That happens a lot in gamedev: most assets…

I think you can delete the history but it’s hard (more than three steps), at least that was my conclusion from the e blogpost below

https://janetgilbert.net/staging/2026/04/27/dealing-with-old...

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

#465

Post by mvkel »

Meneth wrote: post #457
MrDresden wrote: post #133

Earlier quoted context omitted.

I once worked in a git repository that required those kinds of restrictions. This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it). Needing to fig…

Banks absolutely love security by obscurity. No clue why.

It's the most effective kind of security

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

#466

Post by jeremyjh »

Meneth wrote: post #457
MrDresden wrote: post #133

Earlier quoted context omitted.

I once worked in a git repository that required those kinds of restrictions. This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it). Needing to fig…

Banks absolutely love security by obscurity. No clue why.

It had nothing to do with security - it had to do with contractual obligations. Contracts with Apple (also Google, Samsung, Mastercard and Visa) required the product to be kept absolutely secret before the public launch. I was a tech lead with developers working on Bank of America’s ATM client - which had firmware and software updates ahead of launch - and I found out about Apple Pay the day it launched. Across the aisle were developers who supported the debit auth platform and they had no idea either.

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

#467

Post by joshy324 »

a1o wrote: post #459
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.

git submodule update —recursive —remote is that, isn’t? Perhaps throws also an —init if it’s the first time.

[dead]

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

#468

Post by gbalduzzi »

js2 wrote: post #447
dansmith1919 wrote: post #377

Earlier quoted context omitted.

The point is that if it's useless information for 99.9% of users, what's it doing in the UI?

It's not useless information, any more than the tachometer or a temperature gauge instead of an "idiot light" in a car is useless information. Again, "because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!" If you don't want it, use `--quiet`. I like that it's there by default since it's useful when I need it and ignorable when I don't. Of all the things…

How often do you really need to look at that info while doing normal work?

Because to me and to the very vast majority of git users it is totally irrelevant.

It is nice that the info is available, but the more sane default would be to hide under a verbose flag not the other way around.

Imagine typing cd folder/ and have the whole filesystem subtree be displayed in the terminal. You are free to ignore it, but it is useless and inconvenient nonetheless

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

#469

Post by vorticalbox »

Meneth wrote: post #457
MrDresden wrote: post #133

Earlier quoted context omitted.

I once worked in a git repository that required those kinds of restrictions. This was within a bank and the code in question was related to enabling Apple Pay from within the banking application. The consequences of that information and code leaking or being seen by anyone who had not signed the NDA were very serious (don't remember the details but it made the lawyers were extremely stressed about it). Needing to fig…

Banks absolutely love security by obscurity. No clue why.

security by only obscurity is bad. Having both is better.

For example say I have a hollowed out wall that is hidden behind a painting.

Just putting my money in the hole is bad once it’s found it’s gone but if I put my money in a safe in the hole. Well now you need to find it and break the safe and a hidden safe is objectively better than just having a safe on the floor because you need to find it first.

Post reply on HN