Earlier quoted context omitted.
Probably unacceptable as many would have built tooling around the specific default behaviors.
You can have your own version. You don’t have to push all improvements upstream.
Lore – Open source version control system designed for scalability
241–250 of 717 posts
Re: Lore – Open source version control system designed for scalability
#242Just 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.
One might reasonably think that about a number of git's rough edges, and one might be surprised at the reality.
Some years ago, the annoyance of git's inconsistent terminology drove me to look into consolidating "cache", "index", and "staging area" in git's help text and documentation. What I found was that others had (of course) thought of it before, but when they tried to do it, it was rejected by git's gatekeepers.
Re: Lore – Open source version control system designed for scalability
#243Earlier quoted context omitted.
"Lore" is appropriate. Epic games is a very unethical company that steals from people. Myself in paticular. I bought Rocket League the game for linux from Psyonix. Epic bought Psyonix and immediately removed the game clients for linux and mac os. I can no longer play. They stole from me and many others. It'd be one thing if they just shut down the game entirely, but stealing it from only some people while keeping it…
I haven't played it since the buyout either, but I'm told it works perfectly with Proton.
Re: Lore – Open source version control system designed for scalability
#244Earlier quoted context omitted.
Jonathan Blow found it convenient to represent all assets in a large number of text files, to enable merging. For instance he'd have one text file per entity on a map. The game and editor could read either this or the compiled binary version.
Jonathan Blow works with extremely small team sizes relative to the big studios. When you only have a couple people working on a project you don’t need all of the same coordination features.
Re: Lore – Open source version control system designed for scalability
#245Earlier 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's not something that you can do in git: it's all or nothing. That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
Re: Lore – Open source version control system designed for scalability
#246For 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…
Git LFS is a major PITA, and if you use GitHub is even worse since there are quotas and rate limits that are charged separately.
Re: Lore – Open source version control system designed for scalability
#247Earlier quoted context omitted.
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.
At my previous game-dev-company job we ended up splitting things up into: 1. Code - Git 2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc) 3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else…
SVN makes sense cuz it's done and dusted, but I could see the Drive gettin real messy real fast if things change a lot
Re: Lore – Open source version control system designed for scalability
#248Isnt that what SVN is good for?
Re: Lore – Open source version control system designed for scalability
#249Earlier quoted context omitted.
Doesn't git crypt solve this? You can have encrypted blobs in a repo that will be auto decrypted if you have a working key.
Not really, precisely because it’s decentralized. You can’t audit whether a user accessed one of the hidden files, or really even who can access it once you accept the reality of the risk that some team will put a key on S3 or a shared drive or whatever. It’s fine for things that you want devs to be able to see without the Git host being able to see them, it’s less good at RBAC because there’s no real “identity” comp…
Re: Lore – Open source version control system designed for scalability
#250Earlier quoted context omitted.
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?
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…
Except of course shipping ATI hardware for years afterwards, then also using nvidia, then dropping nvidia and only using ATI/AMD until transitioning to Apple Silicon.