Live data from Hacker News

Lore – Open source version control system designed for scalability

lore.org

161–170 of 717 posts

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

#161
post #91

Earlier quoted context omitted.

> It's probably just something no one has thought of doing There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.

Luckily it’s an open source project so you could go in and clean up the ux.

Probably unacceptable as many would have built tooling around the specific default behaviors.

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

#162

Earlier quoted context omitted.

This is what happens when a kernel developer creates tools that need some kind of UX (I say this both as a shitty UX developer and Linus fan)

He makes a good tool? Honestly I don’t get the git hate on HN. I’ve been using it for years with no issue. I just read the first 3 parts of the git book and never looked back. I even setup a git server at home with the basic tools.

This is definitely a bit snarky but you read any of the documentation at all, and therefore know more than a large percentage of git users about what it’s actually doing. Most people seem to treat git like some sort of mysterious orb which if you speak the right incantations will perform magic for you.

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

#163

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…

There's also a new player called diversion (diversion.dev) which I think may be a YC startup? Anyway it takes a different approach of being more like Google drive but bringing in VCS behavior making it more indie and designer friendly.

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

#164
post #90

Earlier quoted context omitted.

And then they usually back their words by doing things like "you claim that outputting text to a terminal emulator is a PhD level problem, so here I did it in a weekend". Huge teams are more often than not the sign of bloat and inefficiences.

To be fair, game developers have been rendering text on the GPU for over two decades. I've done it in college a decade ago with bmfont [1] (nowadays the engine does rasterization during import). Whoever thought was making a case with "outputting text to a terminal emulator is a PhD level problem" was really out of their depth and was making a case for unnecessary inefficiencies. Kudos to Casey for proving a point. 1.…

I remember when that terminal situation first happened, and my main takeaway wasn't "wow, this Casey guy is a genius" but rather reinforcement of my pre-existing belief that Microsoft is full of incompetent and lazy people. Anyone who has ever dabbled in engine or low-level game dev has implemented basic GPU text rendering at some point.

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

#165

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…

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning). Keys, secrets, etc. yes. But code? What am I missing here?

It's kinda like that, there could be a proprietary fraud detection heuristic in there that you don't want to get out.

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

#167

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…

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning). Keys, secrets, etc. yes. But code? What am I missing here?

Maybe that’s some scoring to decide if you should be able to pay or not with some method.

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

#168

Earlier quoted context omitted.

That sucks, git is so absolutely horrible. It's crazy to me that nobody has made anything better yet. Although I could start that myself and yet have not.

We did, mercurial just didn't win.

[dead]

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

#169

Interesting to note that this does not seem like a DVCS in the traditional sense because it depends on coordinating with a central server where all repositories will be hosted. I can't tell if servers can pull/push from eachother.

It is not a DVCS.

> 3.2 Explicit non-goals¶

> Peer-to-peer decentralization. Lore is centralized by design. Two clients communicate through the remote, not directly.

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

#170

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…

Strikes me as bizarre that payment code would be sensitive, unless it's a security by obscurity thing (which would also be concerning). Keys, secrets, etc. yes. But code? What am I missing here?

Because it's Apple. They are huge, have scary lawyers, write scary contracts, and want to "delight the user" with features only when they announce them. They hate leaks, and demand separate teams for basically any/all development.
Post reply on HN