Isn't this what git lfs is effectively?

This is a very long document that says nothing about chunking at first skim. If chunking is actually wrong, then just explain why, here. Wasting space is not actually a problem if it’s optimized for other purposes instead.

I wrote down some thoughts about a "next generation VCS" in 2019: https://beza1e1.tuxen.de/monorepo_vcs.html

Back then I concluded that it will probably never be built because OSS projects don't need it. Maybe this is changing now as AI allows for larger OSS projects.

Yeah, they should have posted it to LoreHub! I just checked for the availability of lorehub.com, and you can buy it for only ~$13,000 and start a competing business to GitHub.

So it's more like git in practice than git in principle, I guess.

I am not sure it is much of an issue to implement a centralised system to solve domain-specific problems that are caused by or are in the context of inevitable centralisation.

I can see a bunch of media companies liking this, maybe even small design shops. Quite a lot of CMS and change control work for media is not much more than asset management; version control is often a bit of an afterthought.

Web interfaces to this might end up interesting for non-profits and charities with significant media outreach.

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.

Maybe because they want contributions.

They have probably enough _bigger_ projects that dogfoods it.

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.

If you've used git+LFS for any extended period of times, you'd know how often it breaks, especially when used with forges like GitHub. Both GitHub and Git treat LFS as an after-thought and second class citizen.

The fact that it's even referred to as git+LFS instead of just git... If I needed to work with large files frequently, I wouldn't want such a basic feature bolted on. Not a criticism of git, just can see why Epic doesn't use git.

I've used git+LFS for unity projects without much issue. If I was working with more than 2 people, I would definitely reach for something centralized.

What an epic domain name :)

My first thought exactly :(

yeah, that's actually crazy.

I don't know a single AAA (or even AA) studio that hosts Perforce in Cloud at all.

Perforce usually starts out life in a gamedev studio as running on "a spare desktop" which then eventually gets promoted to a real server in a closet.

The most important thing for Perforce is disk, memory and above all: bandwidth (of those things and the network too!); it's also quite latency sensitive since all operations touch the server. So running it far away is never a good idea.

There was some complicated perforce architecture inside Ubisoft to account for this: AAA tends to involve a lot of co-dev studios, so the lead studio would get the commit server and others might get replicas (and you could feel to pain)- but all the perforce instances were actually on the same machines and would replicate to one-another anyway: each project was given a port for the perforce fleet. Really bizarre.

but, that's besides the point. Even the tiny studios run their own locally hosted VCS machines.

Respectfully, "VCS for game development" is not a novel idea in any way, and you have literally zero claim to it. It's obvious that Git is poorly suited for multimedia binaries that are integral to games, so obvious that there's Git LFS which is still just a bolted-on hack when you'd ideally have a system designed for them from scratch. It's also explicitly not specifically "Git for gamedev" -- it's "Perforce for gamedev", as they opt into the authoritative server model rather than Git's decentralized model.

Epic has also been working on this for longer than the three months your repo has been around. This is the launch of the open source project and independent GUI, but it was already integrated with their Fortnite game engine before now.

Your VCS repo is called "Artifact". It seems like a stretch to say that somebody using "Lore" is copying from you. Even if it were called "Pagan" that's still a stretch, but "Artifact" especially so.

I think a VCS written in Javascript is also inherently a nonstarter for any kind of production-grade use case. The idea that nobody else can make a gamedev-oriented VCS because somebody in the world made a little hobby project along those lines is frankly ludicrous.

(Granted, I'm not exactly keen to use Lore myself given the heavy signs of vibe coding throughout the documentation and repo. A vibe coded VCS is also inherently a nonstarter. Here I'm hoping some third party will come along and do VCS for gamedev right!)

I'd also add that there's some element of hypocrisy to criticising Epic here when your own marketing pitch is "I copied Git".

I tried your website, but it just says "LOADING".

How about the last pre-enshittified version of Minio?

This is primarily going to be targeted at Unreal Engine users, for whom the source control tooling they use is the smallest of concerns when it comes to being tied to Epic Games.

I'm not a gamer so I'm entirely ignorant of the situation. What's the root of your objection? The games are proprietary, right? So I figure it's not a Stallmanesque position. Is it a big problem to run games on Windows?

They are so anti linux that they ship a linux version of Lore.

Lore itself is not an example of a program that meaningfully benefits from any of the key features of Lore.

Lore is meant for situations where your repository is going to contain gigabytes of binary files, such as art assets for games. Git is technically great at everything but that, and even the external solutions for that situation still kind of suck.

What sort of scale are we talking about when mentioning tech company's monorepo though?

Not immutable. Not good with binary files.

I tried to give that section of the doc a fair read.

Looks like operational transforms to me.

The doc claims it's the first with this technique. A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave. And yes, Google Docs storage works the same way - there are probably papers documenting how efficient Google Docs storage is, but it's not wrapped up in a full VCS that folks can use.

The example in the doc uses text, and unfortunately I think it's for a reason. I think with large, binary game assets, the most common operation is going to be strings of "replace A with B", and depending on your chunk size relative to the distribution of changes you make on your assets, I see it as pretty close to a wash, for efficiency. Especially considering that content-addressable blocks also solves de-duplication, which for a multi-game studio is probably going to be significant. Especially if they're managing multiple releases, patches, development branches, etc.

The best answer I have is for you to read the "History Model" section of that design doc through the "Implementing CRDTs" subsection.

Why not?

Well it seems to be intended for repos with large blobs like video games so it kind of makes sense that their own pure source code is still managed with git.

Epic's Unreal Engine development is made in Perforce, and then it was mirrored to git/Github. Or that's how it was a couple years ago. That's kind of expected, VCS is one thing, a forge is another thing.

Git does great with text files, but game development contains a lot of binary assets (textures, videos, 3d models) and correspondingly huge repos. git-lfs tries to patch around that, but that makes a complex tool that creatives struggle to understand even more complex. Perforce is a pretty popular solution, and was used by Epic in the past

> It’s optimized for projects—including games and entertainment—that combine code with large binary assets, and caters for the needs of developers and artists alike.

When you have a game that weighs in at 100GB, only a tiny fraction of that is built from code. The rest of it is binary assets that most VCSs struggle with. What makes this worth considering is the fact that they designed it to handle binary assets.

Apparently, how it handles binaries when developing games.

Not sure why the downvotes, as this is a genuine question. In game development svn is often considered due to issues that git has with large files. Just stating what currently is done, and curious to understand what lore improves. Svn is still going strong among many shops.

The comparison with perforce explains more

I can’t remember the last time anyone actually played the game they got for free on epic’s store

The excessive emojis in the README don't inspire confidence

It has an MIT License

Pricing for on-premise deployment is “talk to us”.

No thank you.

The way games on Linux work today is most are compiled for Windows. There are a few exceptions like Civ will in many cases provide a fully Linux native build. But even in that case on Linux you can choose whether to run the native or the Windows version.

When you download a Windows game on Steam you will go into the Settings and select "Compatibility Layer" and there you will find several versions of Proton. Proton https://github.com/ValveSoftware/Proton is a pre-configured wine bundled with windows DLLs and Linux .so library files. This makes Proton Immutable for any given major version. Meaning you can run Proton 2.x for your game if that's what fits your situation. It's always there if you need it for your specific games. Steam launches this in a container. It is not emulated. It is a fully native implementation of the API that in many cases achieves superior performance.

This is why you will sometimes see the joke that the most compatible API for Linux is actually the w32 API.

This API is now at the point where pretty much everything works unless you cripple it on purpose. And that's what Epic Games is doing here. There's no technical reason for this. It's a business decision that doesn't even make sense because frankly I could vibe code them a linux native game client that launches their games properly on linux in a few days.

> they require you to install unrelated third-party software you'd rather not install (and which at least in the past has been known to snoop your data without consent).

can you elaborate pls? I'm a little not in context

They gave away Death Stranding awhile ago, and I hear that one is good, which I don't dispute given its Kojima origins.

But Kojima games require me to be in a very specific mood and I have been trying to work my way up to it.

I mostly agree. I think for games you want per commit versioning 95% of the time. You don’t _really want developers building with cherry picked old revisions etc, but you don’t want an artist to have to pull down the 8TB of new art content that was submitted in the last 48 hours to update a texture.. the only way to do that is per file versioning!

I braced myself for this, and instead found that it worked surprisingly well for my uses. I only manage 4 gigs though.

You gave me a flashback to that time I tried to use Git Annex on a moderately sized dataset and it resulted in a sysadmin at rsync.net personally contacting me to see if I needed help with whatever poorly written script was hammering their service.

In other words: No, absolutely not.

Mercurial is a bit better, but not by much it had slightly better large file support historically but I wouldn't recommend it.

Perforce is more the IBM of VCS. Older than it has any right to be. Has quiet "dark matter" support contracts with a lot of companies you wouldn't think need Perforce, but they've been using it for long enough they aren't going to change. Some of those support contracts included complicated forks and homegrown solutions that are so sunk cost as to be nearly black holes (and sometimes so different from baseline Perforce as to be evolutionarily different species).

Well another factor could be that Perforce is a lot easier to use than Git - Actually, would like to think am good with git, but sometimes just wonder how it became so big considering the simple or important things (like check-ins and merges) are so complicated.

It's not even baked into Google anymore.

Because it's not so cleanly cut. Editing a level might touch several files without you realising, you might move a mesh file which causes 100s of references to update across 100s of files.

For example, you want several people collaborating on a level. Say a level designer, an artist, a lighting person, audio. Usually you split this into several files to allow for the collab but you're bound to hit moments where you need to edit across the board. The level designer moves an area which causes the light, audio, meshes to move. If you don't have a way of knowing someone else is working on those files you're going to step on a lot of toes.

Whether this should live separately from source control is a fair question, but it's just a simple place for it as it's tied directly to the files.

Also, the outcome of a mistake is quite high, it could mean a whole day or two (a week?) of wasted work because you didn't realise someone was also editing the same file.

10 months or so ago I believe HN posted "The future of Large Files in Git is Git" : https://tylercipriani.com/blog/2025/08/15/git-lfs/

So is it the future now?

Yeah, engineering is another use case for Perforce, will be interesting to see if Epic pursues that market too. I know UE has some use in industries like architecture and professional simulators.

There are some projects:

* https://github.com/jj-vcs/jj

* https://nest.pijul.com/pijul/pijul

With respect, were you around to use any of its predecessors?

Git is fit for purpose. That purpose is to host a monorepo, with out a lot of 3rd party dependancies, distributed, patch based.

Thats not how everyone else works.

We're all using package managers to help with massive amounts of 3rd party dependancies (why are you version pinning in any place other than your repo, why arent you pulling updates through your repo and reviewing them)

We're reliant on tools like artifactory to make sure those depedancys dont disappear or are not corrupted.

We use yet other tools to manage our binary files (this tool would fix that).

Github, gittea, gitlab, bitbucket... have all added piles of tooling around git, that are grafted on around its short comings.

> It's crazy to me that nobody has made anything better yet.

Because our entire industry has fallen into the rut of "more tools", of stacking turtles (https://en.wikipedia.org/wiki/Turtles_all_the_way_down ) rather than fixing the real issues that hold us back.

> Although I could start that myself and yet have not.

Because unless your a Google or a Linus, no one is going to look twice at your tool for something that is this important. Im not even sure that epic games has the good will, or trust to launch this.

I am going to give them the benefit of the doubt and take a long hard look at it, but my optimism is tempered. But unless it offers a LOT more than git, the extra overhead (lacking IDE support, deployment changes and all the other tooling in GIT's orbit) it isnt going to be a worth while change.

turns out version control is hard

We did, mercurial just didn't win.

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.

That's fine for database-like meta-data (e.g. game entity properties), but not for images, videos or audio files. Just writing those as hex dumps into text files doesn't make them any easier to merge.

You really can't merge binary data, such as textures, meshes, audio, etc. It doesn't matter if you base64 encode the data and stuff it in a text file: it's a jumble of data (assuming this is the implication of what Blow did).

He uses SVN and specifically has stated that Git isn't suitable for the work he does due to big binaries in source control.

How do you merge changes to a texture, mesh, audio file, etc?

Git LFS for example does not support file chunking. So a single byte change on a large (100s of gigs) file means downloading the whole file again. Lore does chunking of binary files which means faster downloads and better de-dupping on the backend.

I haven't made games for a long time so I can't speak for my experience, only my friends. From what I understand (1) Perforce has decent integrations with the game engine editors my friends work with, so editor support is no factor for them and (2) it has better delta support for the file types they work with - I believe Git LFS mostly uses a generic xdelta diff which is kind of mediocre at everything versus Perforce can understand different file types and be extended to support custom types.

I guess you never worked with anything but git? The devil is in the details, and those details generally suck more in git (or generally: distributed version control systems) than in traditional centralized VCS's.

Also git-lfs is a crutch that breaks more often than it works :/

(I agree though that for small game projects, git is mostly 'good enough', even without lfs).

Git LFS breaks so often that it can't be seen as a serious professional tool tbh. I've had nothing but trouble with it. If it wants to be serious it needs to be built into Git, not added as some after thought.

There's also the tooling. Game teams have artists and designers where baroque command line incantations are headwinds to their workflow pace.

For the longest time Git tools were really poor. In recent years there's a few ok ones, like Git Fork, though I wouldn't know if those tools scale to the level of a AAA team size repo and not fall over.

don't think it supports branches

it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go

no-verify cancels local hooks, remote hooks are unaffected.

Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.

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.

Maybe you could go to linus and demand enterprise features and support.

;)

Yeah, I can't edit my first post, but should note that if you don't want to rewrite history of the submodule, it also at least lets you consistently do shallow clones of the submodule - various git-related CI/CD operations on the main repo won't work with shallow clones, so it's a pain if you have to pull in a million old versions of binary dependencies just to run gitversion.

As far as rewriting the history of the submodule goes... that's really something we're okay with - for us, the alternative to the git submobdule was just an SMB share - indefinitely keeping old binary dependencies isn't something we want to do.

Isn't centralizing systems over time more common than not? Another example is the Internet: websites do not have a uniform distribution of traffic

I was excited about this project, but you convinced me to look into it and yeah, I'm seeing emdashes and overly verbose/elaborate commit messages :(

What a shame

Git submodules are the regular expressions of version control.

You'd have the non-NDA, core stuff in the submodule. The submodule can then be referenced by the big, driving NDA repo. And maybe another repo with a non-NDA, likely simpler "shell" that lets non-NDA devs work with the codebase.

If you need to NDA the core stuff instead and thus can't pull it as a submodule, the only thing I can think of is to pull the core as binary/compiled artifacts.

You can set up submodules to not pull the other source repo by default tho

No, I meant the locking. Being able to branch a lock so you can edit an asset in a feature branch and then discard it (or force a merge)

Yeah, it's a cool idea, but for proprietary formats, it's much harder for outsiders to do, and the original companies just don't see it as something they should take care of. My gut says there's too many changes that couldn't be cleanly merged anyway, so they think it's not worth the bother. (And they might be right.)

At least for code, I know people have attempted format-aware, structural diffing for a while. The Lisp communities tried a few times, because s-exps are trivial to turn into trees. None became the standard diff tool, though. However, modern tools like difftastic used tree-sitter to bring a lot of language-aware diffing to the masses.

- https://docs.racket-lang.org/sexp-diff/index.html

- https://github.com/michaelw/mw-diff-sexp

- https://github.com/lambdaisland/deep-diff2

- https://fazzone.github.io/autochrome.html

- https://github.com/Wilfred/difftastic

You mean `jj advance bookmarks`? It still seems like a pain to not just have it happen automatically on `commit`. (I use the "experimental" auto-advance-bookmarks feature, but it's got a lot of papercuts.)

You can also just do `git commit -a` to commit all modified files.

> I feel like other commenters are being obtuse on purpose and avoid the point?

nah, people are just built differently. Not everyone gets frustrated with "learning to remember", and then some do. Both are valid. The people who seem to be obtuse to you are in the first group, myself included. I didn't instantly catch the fact that instead of `svn commit` I have to now do `git add`, `git commit` and `git push`. But, and this is the key difference, when I forgot I just checked my bash history to recall the sequence. It doesn't bother me because I know either of two things will happen:

A. Over months and years, you then understand how things work and its second nature.

OR B. The tool was just a one-off and you won't use it after some time, so it doesn't matter you won't recall the steps.

Its the same with any professional tool, really - even outside software (think carpentry, for example).

"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

Kubernetes and the one I'm working at right now.

I meant that, as a web accessible build and review tool, Horde is not as good as the rest of the big players. You would still use gitlab et al to run your UAT script and that would do whatever distributed build you want.

I agree that it might not be feasible advice to try to force of of these other SAASed into the mix. It's just that Horde lacks a lot of niceties that the greater tech community has.

But it's more like a fundamental design choice.

Perforce predates Git by a decade (but your overall point is valid)

From my viewpoint, a lot of the submodule problems are effectively same as the monorepo problems, including how you end up with both problems. There certainly are factorings of projects into "microservices" and moving the dependency management problems out of source control to package managers of different types. Microservices and package management sure do have their own problems and trade-offs and there isn't a "universal solution", just what side of the trade-offs you prefer to be on.

Yeah, decentralization is an important principle to git and tools to manage concurrency such as "file locking" become a lot harder to do in an a decentralized way than a centralized one. (Pijul has the same problems because decentralization is also an important principle to it.) It is something of a problem space that transcends beyond git. But I also think this is how we've arrived to this moment where the best source control tools have decentralization as an important principle. That 80% case with easy mergeable text files is a lot nicer to work with in a decentralized world because it is "offline-first" and quite capable. It often seems, across a lot of different styles of software development, worth the trade-offs that things like media files are harder to work with. (Again, realizing the obvious problems with game development where that often flips and the majority of work is often in the media file assets as much or more than the text files.)

Reading the docs is kind of a superpower for devs. With AI I think most technology is going to be treated like praying to the machine spirit.

If you don't read the documentation you can't complain if a machine stays a mystery for you. Normally you don't get to use a machine without proving you actually now what you are doing.

No, just different. It's not like he had a goatee.

I intentionally avoid fetch and rebase because you can pull and merge instead

And reflog when you make a mistake.

SVN was more straightforward to use, but that straightforwardness lost a lot in terms of fidelity.

The fact that it was easy to clone a subdirectory was nice; the fact that branches were just subdirectories also was not nice. The fact that tags were mutable since they were also just subdirectories... the fact that every operation you ever did required going to the server (commit, log, checkout, everything) made it a pain if you were on a slow link.

I can't count the number of times I was inspecting SVN history and had to just 'svn log > /tmp/svn.log' so I would have the whole log locally rather than having to hit the server each time I wanted to refine a grep.

We are legion ;)

SVN was actually quite decent for game development, definitely more robust and (non-technical-) user-friendly than git+lfs.

(and SVN isn't really compatible with the work-from-home era unfortunately, you really needed a big server on a gigabit LAN)

Git does record the move, and you don't have to use the git ui to do it. Lore says it requires `lore stage move` to record it. More details in the reply to your other comment.

Guess I never used map+collect in Rust. It's an extra copy. Maybe iter on its own cause that's how you go through non-array collections, same in C++ except C++ is just crappy no matter how you use it.

I like most of those decisions, but they aren't functional programming

> Git knows that the file was renamed even without using git to do the rename.

No it doesn't. Git knows that file A was deleted and file B was created, and if they have the same content then it will guess that it was a rename. But it's a heuristic that doesn't always work. E.g. I think it doesn't try to guess for large diffs, and it doesn't work if you modify the file in the same commit.

It's hardly the same thing at this point. For instance you could say Nginx is API-compatible with Apache, and yes that is correct (Maybe? Let's not split hairs here). But to go as far as saying Apache is state of the art and link to Apache's homepage (like throw2ih020 did) is just like.... no.

I think you think I'm trying to correct/one-up reactordev. I'm not. I agree with him. He's pointing out throw2ih020 is being ridiculous, and I'm pointing out that it's even more ridiculous because it's less than 3.

> The point was that this bothered me when I used git for the very first time

and that is fine. From your original comment, you "just" wanted to save things and got confused why you had to `add`, `commit` and `push`. Its just that you didn't know that git isn't a word processor that gives you a way to save your work - you've done that already when you saved the file with your editor.

When I came to git, I was also confused why commit and push are different steps - so much work, I thought. Until one day it finally hit - wait, this lets me keep "saving" my work locally until I'm ready to upload it - which is when I push.

As I said in my last reply - none of that surprises me. Our provider worked out of the box, fwiw.

afaik they're randomly generated so you're likely the first and last person to see that permutation

Very relatable. I still recall when our team at Microsoft, about 20 years ago, had a dedicated "build engineer" who would be given the task to create a new branch for the product. He would disappear for a few days and re-emerge with the announcement that a new branch had been officially created and was ready to be used. Hard to imagine that in git world.

When I went back to Perforce I was reminded of why that was a thing. You're making a full copy of everything. They recently introduced a virtual copy stream, but I remember people advising against using it, for reasons I can no longer remember. It seemed like a potentially sensible approach.

Oh, and thanks for writing Game Programming Patterns. That was a great resource.

and why don't we just follow decades of conventions and add a --verbose/-v flag to display all the gobbledegook if you really want to, but hide it by default? As far as I remember, the guidance has always been "only print something if the user needs to know, no output means success."

git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.

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.

Submodules ARE multiple repositories. This is not an either or.

And a few of them think that it is corporate structure and development models that are actually the problem.

I'm just asking questions!

And yet, even for programmers, that output is full of info that is useless 99.9% of the time. That is just bad design. It is basically a debug log that is shown by default all the time, instead of written to a log somewhere for the <0.1% time it's useful.

And I point out the attitude because I've seen it for decades and seen the harm this kind of "it's just harmless extra info" type thinking has brought. I don't know what tone you're reading into it, but I'm quite literally and explicitly criticizing the attitude, not you personally.

I'm a programmer and I understand Git internals decently well, but unless something went wrong, I pay zero attention to the verbose output of `git push`. BTW, isn't "avoid unnecessary output" one of the Unix philosophies?

> FFS, git is a tool for programmers.

We already said it has a garbage UI, you don't need to repeat it

But jokes aside, usually the reason something is considered a "tool for programmers" and not just a tool is because the UI sucks.

Cache is like the old name, index is the new name, because the implementation didn't really make sense to use as a term for the users. Staging area was invented by third-parties as a term for training. Now Git uses --cached to mean only work on the context cached in the index and --index to mean also look at the --index. --stages exists as an alias for --cached for the people who want it, but it has no additional meaning and is not advertised in the documentation.

The actual documentation is actually sensible, the issue is just that most people just learn from third parties, who are lax with terms.

> At the end user level, "cache" is only used as an adjective these days; "cached", meaning "contents cached in the index, not the contents in the work tree". We could have called it "indexed", but "cached contents" was an already established phrase from very early days to mean that exact concept, and we did not need another word that meant the same thing.

> There are some commands that take --index and --cached options, and even some that can take both (but not at the same time). Many people find this confusing, but there is a pair of simple rules:

    "--cached" always means "work only on contents cached in the index, ignoring the work tree";
    "--index" makes a command that usually works on files in the work tree also pay attention to the index.

> Here are a handful of examples.

    "git apply" usually patches the files in the work tree without touching the index.
    "git apply --cached" only updates the contents in the index without modifying the file in the work tree.
    "git apply --index" patches both the contents in the work tree and in the index.
    "git diff HEAD" shows a patch to update the contents in the HEAD commit to contents in the work tree.
    "git diff --cached HEAD" shows a patch to update the contents in the HEAD commit to contents that is cached in the index.  "git diff --cached" is a short-hand for "git diff --cached HEAD" only because the HEAD commit is what you most often would want to compare the cached contents with.
    There is no "git diff --index HEAD" (yet); it would imply showing a three-way diff between HEAD, the index and the work tree.
    "git grep" finds matches in the work tree.
    "git grep --cached" finds matches in the contents in the index.
    "git rm" removes both the file in the work tree and the corresponding path in the index.
    "git rm --cached" removes the path from the index, leaving the file in the work tree untracked.

Yes.

I feel like you’re either misunderstanding the entire thread or being obtuse on purpose.

The point is that “Delta compression using up to 10 threads” means nothing to most users - it’s also not a progress thing. Hide it unless the user does -v or something.

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

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 a joint demonstration of the Radeon card that was going to be in the system, and never partnering with ATI again.

https://web.archive.org/web/20001216031800/https://www.zdnet...

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.

> security by obscurity thing... What am I missing here?

You are looking at the problem from the wrong direction.

If you build a honeypot, to trap hackers, does it behove you to explain what the bait is, and how the trap works?

Know your customer, fraud detection heuristics, finger prints, behavioral triggers are all areas where banks, and financial institutions need to keep the sauce secret. Telling the other party "how" you catch them just gives them the steps of what not to do.

The code revealed the existence of Apple Pay, which had not been publicly confirmed.

It seems this wasn’t about the code itself, it was about Apple Pay not being announced yet. So only people under NDA would be allowed to even know what they are working on.

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

Yes Apple Pay relies on security through obscurity even today. See the Veritasium recently made a video about it https://youtu.be/PPJ6NJkmDAo?is=iUuJ0W9xUHF_6gTU

The non-strawman version of "security through obscurity" is the belief that a system is secured by means of keeping its mechanisms secret.

Suppose an organization doesn't believe such a thing; it's still more secure to keep code secret than not.

Obscurity is a valid layer of security, just not a valid corner stone or linchpin of security.

In particular, when code operates as a service (end users don't have the executable code on their machines) then protecting the source code is a real security measure. Without it, attackers can only probe the service as a black box, guessing about what it is doing.

There is a bunch of mundane stuff in the banking/finance world masked off by paperwork.

It's not sensitive in the leaking state secrets sense it's sensitive in the risk adverse lawyers on both sides think it's sensitive.

The Bureaucracy exists to perpetuate the Bureaucracy.

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

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.

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.

Banks run a lot of code as a service. Most people never get to see the executable code. If the source code for those services were easily visible to employees that don't need to have access to it or external consultants and such, that would be monumentally stupid.

It's the most effective kind of security

Great, then your choices are (a) try and probably fail to get your changes upstreamed and/or (b) maintain your own fork of git forever.

This is very much a "if you don't like X about your country, just move to a different one" kind of "solution". The costs are extreme to the point that pretending it's viable is insulting. Really it's just a way to silence legitimate complaints.

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

> It’s just GitHub became popular because people didn’t understand that you can rebase from any remote source.

If everyone uses it wrong, it was designed wrong. See Q-tips.

git is so agnostic about all this stuff that you can even merge completely disparate, unrelated repositories (for example, my own primary "job" repository, and the linux kernel) into the same on-disk structure. Of course, doing so is useless because none of the commits from one repo has any relevance to the other. But because the commits are identified by true GUIDs, there are no collisions, and both sets of commits can happily exist in a single repo.

It's of almost zero utility, but it does (for me) heighten the beauty and elegance of the concepts behind git (and even, the actual implementation).

Funny because `git pull` is an abstraction like you talk about. It's a `git fetch` followed by a `git rebase`. Staging or `stashing`, it's all just leaves on the merkle tree. The concept of time/branches/doesn't exist. Only previous hash, current hash. It's simple and people have ADDED complexity to make sense of it (coming from other VCS').

Agreed. I use and love git crypt, but it doesn't get enough use. I think because it's easy to screw up gpg keys. Most of my uses (for one to three devs) have become symmetric keys shared out-of-band instead of using gpg keys because we've had lots of onboarding pain even from people who are quite competent. There are just a lot of sharp edges in gpg that you don't know when you don't know.

You can use Mozilla SOPS instead with IAM roles and KMS instead of gpg. They also shifted to AGE over gpg.

Tech in general, you’re spot on though.

thanks for the history on this, funny stuff:)

Ah! thanks for clarifying. :)

I respect his work, but I had to unfollow him on Twitter because he was so condescending to everything and everyone except his loyal fan base.

He’s in a category of influencers who post constantly about gripes and grievances and smug superiority. Some people like that content but I can’t stand it.

I really like hearing about indie development and small teams, but you don’t have to present everything as condescending superiority over the industry. That’s not the part I find interesting.

I’ll chip in here and say theres ime a world of difference between the amount of condescension and acerbic noise produced by Blow versus Casey. Casey comes of as grumpy but fundamentally pretty respectful in the stuff I’ve seen him in.

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.

IMO this is just garden variety effects of being a programming influencer. It’s a weird position to be in.

I think being influential just does that to people, with high regularity.

Isn't that kind of the point though? Doing more with less?

What does that have to with your VCS being integrated with your IDE? Isn't resolving merge conflicts in binary files going to entirely a function of the IDE and not the VCS ? What am I missing?

> Git's design provides zero value and zero affordances for solving the very very real problem of unmergable binary assets.

OK, I think this is well-established by up-thread comments, and I don't disagree with it at all (though note that its not just binary assets, it's anything that isn't line oriented, which includes for example XML).

I didn't realize that LinearIO's comment was really that specific; it appeared to be describing general properties of P4 unrelated to the binary issue.

The 10k tutorials on git might indicate issues with its design, or it might indicate its massive popularity. Hard to say.

I just remember that learning to use P4 required learning a ton of concepts for what P4 thinks your workflow ought to be; learning git has largely just required a simple 1:1 mapping between git commands and the things I do with VCS 98% of the time.

> 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.

100% and LOL. Sometimes I wonder where we'd be if Mercurial (hg) had won that contest.

My counter argument is “what is the right order?” And you’ll say “the way work gets done” (paraphrasing) but then I’ll say “that’s exactly how git came to be”.

You are right that it gives you more options and more ways to footgun yourself but that mostly came after the fact. It does need a simplicity wrapper or some better defaults.

C++ is the same way and is why while everyone hates 95% of it, no one can agree on a strictly superior language.

Originated (or maybe just popularized) by Joel Spolsky, I think?

He did approach it correctly, and then his questions were dismissed because "it needs PhD-level research". If anything, it was clueless and incompetent Microsoft "engineers" who acted as edgelords.

I don't get it. Now your options are to lose your work, or for somebody else to lose theirs, or, maybe an un-fun manual merge process - and this after you've both done the work! With a per-file lock, on the other hand, you can't start work until you've got the lock, which prevents others from starting work on that file in the meantime.

(It's usually possible to bypass the locking mechanism, but this is not a habit people get into, because the end result is the situation you describe, and nobody wants to end up there.)

We seem to be in some kind of local minimum here, but perhaps LLMs might help us escape it by facilitating the creation of more merge tools.

Honestly, when our backend team merged into one that was using Perforce for the backend learning how to use Perforce wasn't realistically even a blip on the radar of what to get used to. I was against it at the time for what we were doing but with the benefit of hindsight I can say that I prefer something like Perforce if someone can manage it for me, or it's a set-and-forget type situation; I don't personally have a lot of use for the distributed part of DVCS.

Currently I use Fossil for most projects, but it's not a compelling choice (just like git) for when you have binary stuff. You've got `fossil uv` for unversioned files, but I think I would rather just sidestep the entire problem with a better versioning model than what we've settled on for text files.

It's anywhere close to open and requires vendors to seek approval from Apple for every implementation - Apple just has the market share to make everyone dance to their tune.

Same here in australia. We had NFC payments ("tap and pay") since ~2006. Nearly a decade before apple pay launched in Nov 2015. For us, apple pay was like "oh, I can use my phone instead of my credit card? Neat."

People use it everywhere here, just because its easier than carrying around a card.

Many countries in the world have local systems for quick, direct bank transfers encoded with QR codes to be used by local payment systems or local banking apps.

Not sure I understand? Sounds like a temper tantrum to me.

Four words: You're holding it wrong.

Ultimately, it is the CEO who has to take responsibility. They are the chief executive officer, after all. And they are well compensated for it.

I apologize if I came off harsh and combative. Gamedev is a passion for me and I spent many years in that field, including working on proprietary version control systems because existing ones like SVN, Git, Perforce...etc did not fit the needs of the team.

One of the things I very frequently heard from the non-programmer disciplines was how obtuse and indecipherable the existing version control systems were. That is where I'm coming from.

Your knowledge is still appreciated, by me as well, because while I am well familiar with the way git works, I have worked with many people who were not, and did not have the time or budget in their minds for understanding it because they had many other concerns. That is what I mean when I said that I worked with some brilliant people -- I could not do even a modicum of what some of them were capable, and likewise they probably weren't capable of the same modicum of what I was doing.

I don't know what specifically the GP post was trying to insinuate, if anything at all, but it resonated with me as someone who had experienced the same thing many times over in my career. And I probably judged your comment a little harshly on first read, which is mea culpa. You provided good information for those newer to git and seeking to understand how it actually works besides the cheat sheet guides you so often find.

> Git is a tool by programmers for programmers. If folks outside the programming community are able to use it, great, but that's not its target audience. You don't need to convince me why git isn't suitable for artists.

Precisely, and I think Lore is an interesting proposition for exactly that reason.

While I agree that git is a tool for the development of an operating system kernel, it's become clear that this is not the general perception of it. I don't mean those of us who have followed it throughout it's evolution, but those that are not 'in the know'. I have heard probably too many programmers pushing it as the end-all-be-all solution for version control even in environments not appropriate for it.

I will disagree that the output is too complex; it is. And yes, the large binaries issue is also a huge challenge to it's use. There's only so much time in the day, and when you work in gamedev there are often severe pressures to perform, and spending extra time to get into the weeds of a version control system is often not possible without sacrifice.

No, it's mostly nonsense to them.

You know what's a progress indicator? An actual progress indicator. Not some text telling you such and such process is 1234/5678 steps done...followed by yet another line of text telling you that the process is now at step 3 of 20. It could just be a % indicator with a spinning cursor, unless the -v/-verbose flag is present.

Of course artists can learn to understand what all this means; But that is not their job, they have other things to deal with besides the esoteric and overly verbose CLIs we programmers often make.

Yes, then it breaks because you gave your artist an SSH link to clone and LFS requires a HTTPS auth token and exits with terse errors.

Or, you need to lock your files and git doesn't really support that.

To be fair, your hypothetical is true: UE5 supports Git as a backend, you don't need to run git commands (most of the time), but in practice even in the best circumstances: Git for game dev is brittle, slow, and extremely space inefficient.

Worse still: people try pushing their "short lived branches" workflow when using Git, which is *not* how gamedev works, especially for artists. Longer lived changesets are more common. (in Perforce these are called Shelves).

> artist should use any of the nice frontends that work on top of git and hide its verbosity.

Right up until something goes fucky. You know how many times I got messaged by someone dealing with vcs going wrong for them at a late hour in the evening? If I had a nickel for every time, I wouldn't be rich, but it probably would have bought me a gallon of gas.

It's not the verbosity strictly speaking. It is the minimal level of abstraction between you and the vcs and it can hardly be helped by a 'nice frontend' when things go wrong. And they will; they always do.

In fairness, AAA games are practically over. They have grown too bloated, take too long to develop, and, with the culture wars raging in the background, almost every AAA game steps on at least one landmine and loses a large fraction of its audience before it is even released. Sad, really.

There are real problems, but Jonathan Blow doesn't limit his criticism to those problems. He just indiscriminately criticizes everything. He's turned into the type of critic that is a broken clock that happens to right twice a day.

His criticism isn't limited to AAA game studies. He's a vaccine skeptic and is pretty heavy into far-right influencer garbage. All very surprising if you only know him from his games.

This Tweet is a classic https://x.com/Jonathan_Blow/status/1854708962462982465

Jonathan Blow:

> It doesn't help that all males currently under the age of 40 were raised to be supercucks

I started following him for his gaming work and talks. His influencer content is something else.

That is what makes it cult like and not a full on cult, there is a lot of truth to what he says. The problems is when the conclusions are extrapolated out to absurdity - it’s hard for me to listen to it. I didn’t take sufficient notes to give a proper recount here and it’s a bit too much work for me to go through it again.

The interesting thing to consider is that it seems fairly obvious from the outside that big game studios are killing themselves. But somehow, on the inside, there are people, of extensive qualification given the nature of our society, who think they're doing the right thing, and that "we" are wrong.

So it leads to the issue of perspective. Somebody has to be right, and everybody thinks that person is themselves, or they obviously wouldn't think what they do think. So in this case he could well be right on both things, or perhaps neither.

I don't know if I agree.

People who moved to bluetooth got arguably worse sound quality.

For wired headphones, there were very few lightning headphones and they mostly sucked.

Now with usb-c you can get a broader range of headphones (because other phones have gone with usb-c).

either kind needs a dac inside the dongle, or the shell of the headphone, or have a bulky external dac.

3.5mm is still king for decent wired headphones/earbuds.

It was wrong then, it is still wrong now.

All my three phones have a headphone jack.

I don't have or plan to have an iPhone.

It still has a lot of detractors but it is hard to beat such a sheer market flex.