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.
Lore – Open source version control system designed for scalability
161–170 of 717 posts
Re: Lore – Open source version control system designed for scalability
#162Earlier 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.
Re: Lore – Open source version control system designed for scalability
#163For 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…
Re: Lore – Open source version control system designed for scalability
#164Earlier 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.…
Re: Lore – Open source version control system designed for scalability
#165Earlier 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?
Re: Lore – Open source version control system designed for scalability
#166Count on it.
Re: Lore – Open source version control system designed for scalability
#167Earlier 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?
Re: Lore – Open source version control system designed for scalability
#168Re: Lore – Open source version control system designed for scalability
#169Interesting 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.
> 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
#170Earlier 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?