You can trust Helix and Perforce because they have been doing this for decades, and this is part of their core business. You know they will keep maintaining the products for a while.
But for Epic, they could give up on this project tomorrow, and nothing will happen to their business. If anything, they'll get some dev resources back which helps their business.
It's like why anyone would trust Cloudflare to continue investing in EmDash over the long run. Cloudflare doesn't care about CMS. Their business is not providing the best experience for readers/authors/site owners. It's just a side hustle that is almost irrelevant to their business.
[0] https://github.com/EpicGames/lore/tree/main/docs/developing/...
[1] https://github.com/EpicGames/lore/blob/main/docs/developing/...
If the roadmap's "Web client and code review tools" could replace gerrit for me, this would be a easy switch.
Moreover, it looks like they designed both the mutable store and immutable store to be able to easily store their state directly on an s3 like system.
There are a number of features that would greatly speed up CI/CD system operations I belive.
A quickstart link is buried in there, and that's good, but the value of the product is multi-faceted and doesn't address data architecture only.
Interesting to see where this goes.
As someone who came from VFX I always found the way Git works to feel very limiting. I feel like it was one of those things that was just so much better than the previous option (SVN, etc) that it blewup without actually being ideal.
Helpful page that gets closer to the details
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 obtain an exclusive lock on some art assets while editing them, because there is no sane way to merge two artists' async edits.
The SOTA in this area is Perforce (https://www.perforce.com/products/helix-core), a proprietary system. From what my gamedev friends tell me, when Perforce works it's great, but it hits enough snags that you need a tools engineer to manage it and occasionally fix issues manually. Git LFS is an alternative, but my gamedev friends all prefer Perforce especially when working on team projects beyond like 3-4 people.
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 objects.
From the documentation, it looks like Lore does a bit better in this regard:
Pushing 1 fragment(s)
Pushed 1 fragment(s), 124.00 bytes
Pushing a3f8c2d1... to branch main
Pushed revision 1 -> a3f8c2d1... to branch mainPerforce definitely needs a challenger. It is not the incumbent because it is particularily simple to use or administer. Git is actually way simpler when it comes to branching operations for example.
The reasons why p4 is often preferred in gamedev have already been mentioned in other comments: large project support, permissions, file locking and so on. Another key reason p4 is the king for Unreal dev is just how well it's supported inside the engine. Not perfect, but it's the best supported VCS because it's what Epic uses. Even the Git plugin is painfully unfinished, because Epic does not internally use it. So with Lore I expect them to give it first class support. I'd recommend Git a lot more if the support in Unreal was better.
(background; I've been in gamedev for almost two decades now, 2-200 person companies, every kind of engine and version control system. I prefer git where I can use it: for Unreal that means small projects and/or tech savvy team members. Pick the tool that is right for the job and the team.)
It does show its years though. We were one of the first users of the Perforce cloud offering, as we were small and didn't want to self-host ourselves, but it was a bit of a rickety experience. You had to register an Azure account in order to be able to access the service, and you had to ask support to modify things like triggers. Coming from the world of GitHub and other SaaS products, you could tell it was an attempt to retrofit an older model into a new skin.
The Git LFS path has some unofficial support as well, but you are on your own when things go poorly. Epic doesn't provide much help there.
Competition in this space is welcome, especially if they're planning to make it fully officially supported by the Engine.
I wrote about why merging files isn't as common in the world of game dev for folks coming from the world of text: https://www.kuril.in/blog/why-game-devs-dont-merge-files/
>Lore, formerly called Unreal Revision Control, is the built-in version control system for UEFN (Unreal Editor for Fortnite), where creators have been using it to version their islands. It is also seeing progressive adoption by internal Epic teams, and is being implemented as the backing store for UEFN’s cook pipeline, where it replaces traditional intermediary storage layers—eliminating redundant file transfers and significantly reducing the time between publishing changes and those changes being playable.
Surprised it is in Rust and not Epic C++ or Verse. I wonder why.
- Pachyderm (Go): https://github.com/pachyderm/pachyderm
- XetHub (acquired by HuggingFace): https://huggingface.co/blog/xethub-joins-hf
- LakeFS (Go): https://github.com/treeverse/lakeFS
- Oxen (Rust): https://github.com/Oxen-AI/Oxen
I guess with AI, anyone can vibe code a content-addressed, chunk-level deduped, versioning system in Rust these days...
But jokes aside, Lore seems really cool! What's interesting is the realization that different domains/industries have similar problems, but they don't seem to be cross-polinating. In this case AI and Gaming both need a storage system that can version control large binary files at scale. I think there's lots of opportunities to share ideas here, but perhaps the lack of idea sharing (currently) creates opportunity!
Looks very git-ish. But probably better equipped for large binary files.
echo "Hello, Lore" > hello.txt
lore stage hello.txt
lore status --scan
lore commit "Initial revision"
lore pushI also don't see any sort of GUI client? So the whole art team is going to have to get up close and personal with the CLI
Oof. So this isn't compatible with any tools that move or rename files. I can't see how this will be acceptable for real-world use.
[1]: https://gavinhoward.com/uploads/designs/yore.md
[2]: My WIP VCS has been named Yore for at least two years; I did not copy Lore's name.
Epic interviewed me asking all sorts of questions about my customers and use cases.
"Pagan" "Lore" lol Our site used to say "Folklore" at the top of projects.
They still don't really understand the customer or use case, so have fun.
I'm trying to figure out what Lore can accomplish that git+LFS can't. I've read about big binaries chunking, native interface and permission, is there anything else? Weren't those problems already solvable in the git+LFS ecosystem?
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
EDIT: and then an example for the merge stuff I couldn't find while typing before: https://mergiraf.org/ and HN discussion a few years ago: https://news.ycombinator.com/item?id=42093756
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".
Anyway it's probably fine software and I am genuinely going to give it a shot for a usecase I have involving large image files. But the LLM-generated docs don't inspire confidence.
[1] https://epicgames.github.io/lore/explanation/system-design/
[2] They literally have a section header "10.1 Revision state as a 320-byte fragment". The byte size isn't even relevant in the code as an implementation detail, much less belongs in a design doc. No one read this doc before publishing it.
On the flip side, I expect the project itself will be workable - well, assuming they're actually using it themselves! UE is a big pile of Stuff on its own, and Fortnite must have god knows how much additional crap in there, so if this is (or will be) their replacement for Perforce internally, then it'll be getting a good deal of testing. (If they're just chucking it over the wall, though... well, sheesh, you first...)
(Perforce is the standard thing for games, and pretty well it works too, and hopefully this will deliver it a well-needed kick. It was sold to private equity about 10 years ago, and it feels like they've been coasting ever since. (Perhaps users in other sectors are happier though?))
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.
However combining some of the flexibility and workflows of git with the ability to deal more efficiently and effectively with large asset files is something that a hell of a lot game engineers would be interested in. And having the virtual checkout as a feature out of the box for folks used to half terabyte repo sizes is definitely a huge plus.
This announcement is definitely a big deal, and if the promises for lore actually measure up, we could be seeing the beginning of a switch over to open source version control for larger asset heavy games where git was still not a great fit.
Will be interesting to see what the public code hosting platforms do (github), and whether there will be any major structural changes to git (I'm thinking not likely). I wonder if Epic will make a play to take business away from github or gitlabs.
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 go back and forth early on but once it's done no one will touch them ever.
Well… perforce does get the job done, but it does need a lot of hand holding from an admin (and you need someone who knows p4 server if you’re using it). It’s also stable in the sense of “it has exactly the same feature set as it did 15 years ago, and branches (streams) are considered modern”.
That's one of the features of Git LFS is separately managed storage and lifetime.
You are correct that GitHub does not offer that feature.
https://janetgilbert.net/staging/2026/04/27/dealing-with-old...
This is used so e.g. an artist gets a repo that contains sources for the art assets, while a programmer gets the same repo but instead of art sources, it downloads the already produced binaries. As a SE, you just want to build the code, and don't care about 800 GB of art asset sources.
The git support for new employees drops basically to zero.
I’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
gritzko@spot ~/beagle $ be get
19:07 get ?#0ac49e6a
16:58 post ?0ac49e6a#POST-018 put:/post: banner on stdout
19:07 new beagle/test/be-post-put-banner.sh
19:07 upd dog/INDEX.md
...more stuff...
19:07 del test/post/01-bare-msg/01.put.err.txt
19:07 del test/post/01-bare-msg/02.post.err.txt
19:07 get abc?4222dfabAs for Verse vs Rust, Verse is used in UEFN experiences, but it is _far_ from any kind of production state. It's also intrinsically tied to UEFN. It's not like you can download a standalone compiler or REPL for Verse.
Don't be too hard on Lore.
Still the porcelain is more like cold stainless steel
It also makes diffing hard, as well as diff viewing.
Keep slowly copying other people's ideas without a clue why you are doing it.
Keep losing Fortnite to Roblox and random indie devs. You think copying another person is going to help you? Lol
That's because you have no clue what it is, or why it's in JavaScript.
Nothing else you said is interesting or valid.
Keep copying other people without a clue why you're doing it. Let's see how many customers you get.
> Fortnite
The only cool thing they did (technically they didn't) - a game that is becoming a platform they can't handle.
> 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.
They dropped the "folk" and just made it "lore", it's too close to our branding. It makes no sense for Epic - their site is basically a vibe coded trash version of our real one lol
All Epic does is copy other people, that's why Fortnite sucks now and the company is going downhill.
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 figure out a way to protect those parts of the codebase it was decided in the end that the "easiest" way of doing this was to split the repository in half, with the actual artifact building taking place from the half that had the NDA code. The rest of the application (basically the whole application) was then used as a dependency by it.
Still didn't quite solve the issue, but access to that repository was heavily controlled.
Git enthusiast would often tell you to do this separately with a submodule, and set permission on the version control forge software level (which means Gitea/Github private RBAC access to certain repos for cloning), sure, but that is also painful as hell.
But my point is that all of this is exactly by design from Linus Torvalds's need for Linux Kernel to replace BitKeeper. Git simply isn't the tool for everything, it was developed for a software project with liberalism in mind, but corporate stuff is monoculture and prefers proprietary, shut-in model, and the eat your own dog food mindset, and no wonder it is so painful to deal with.
Git has no built in authentication or RBAC. Thats not what its for. Its flat file source control.
I swear loads of people havent a clue how git works or why it exists...most of the git based cloud services out there are 90% additional crap bolted on.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
At my dayjob we used Git LFS for a bit, but foud it unworkably clunky - we eventually found it easier to just make a separate "LFS" repository and add it as a submodule to the main monorepo. Now we can rewrite the history of the LFS repo on an as-needed basis.
The objects are referenced by trees. A tree is just a directory.
The trees are then referenced by commits and/or tags into a DAG with named pointers into various parts of it (which are your branch and tag references):
https://git-scm.com/book/en/v2/Git-Internals-Git-Objects
Because it would be terribly in-efficient to have a bunch of loose objects, git periodically groups them together into packs. To save space, the objects are compressed against one another (delta compression) within the packs.
https://git-scm.com/docs/git-pack-objects
https://github.com/git/git/blob/master/Documentation/technic...
When pushing or pulling, the git transfer protocol basically enumerates what objects each side has so that it only needs to transfer the difference. On top of that, it delta compresses the objects on each side that aren't already grouped into packs against each other to save space.
https://github.com/git/git/blob/master/Documentation/technic...
Because git is an open-source project written by nerds, it shows you all of this information. Feel free to ignore it!
But if you really want to know, it's all documented both in the git book and git documentation directory, both linked above.
(Caveat: I'm working from memory and surely got some detail at least slightly wrong.)
I’m starting to come around though. From a UI perspective it’s a major improvement on git. The branching workflow is something that has taken a bit to get used to though.
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, Perforce hasn't done anything with its industry position. It's expensive as hell and they don't have operational costs related to hosting (you have to host it yourself, and honestly, for performance reasons you really want to- despite it being a real pain to maintain passed first install). There's some echoes of stuff they try but they have absolutely no solid direction and nearly everything they've been doing cuts against common sense or their userbase, while their core product keeps getting renamed but no actual improvements.
It's a lesson in how proprietary software is really a prison.
I wish I could use a better code review tool than Swarm.
I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
and I wish I could run a distributed storage backend instead of relying on a big fat SSD and journalled backups that can't be restored because licenses are tied to the IP address of the main server.
It's forgotten technology, and the company that operates it is a zombie.
I'm not just picking nits here. And this is not cynicism.
so there you go.
> Open-source the desktop client so the community can build on its full graphical experience, not just download it. An early desktop client already exists as a binary download, but it isn't open source yet — it depends on some proprietary components, including Epic's internal design system. We're working to make all of it available in the open so that the client can ship as source alongside the rest of Lore. Lore is an open project, so it is important that the desktop client — which will be one of the main ways many people will interact with Lore — is also fully open so that the community is free to review, extend, and shape it.
they do say they will open source it, but who knows:
"It isn’t open source yet—it currently depends on some proprietary components, including Epic’s internal design system—but we’re committed to open-sourcing it in the future"
https://gitolite.com/gitolite/index.html
It has fine-grained permissions but works with regular git clients.
It was designed with large-scale environments in mind. I’m aware of several deployments managing hundreds of petabytes of data and billions of objects, which is why lakeFS does not use Git’s Merkle tree / directory tree approach.
Disclaimer: I’m one of the project’s co-creators.
Suppose you make a 1 kB change in a 50 MB file. That causes a 64 kB chunk to be created and stored. Disk space is wasted.
But since the 50 MB file was already stored as a sequence of 64 kB chunks, there is an existing 64 kB chunk that is very similar to your new 64 kB chunk. You can store your new chunk as a delta to that, so only ~1 kB of disk space is used.
Admittedly, it's complicated and inelegant. But it allows both deduplication between files (one of the reasons Lore chose chunks, apparently) and efficient space usage for small changes.
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.
This is the type of attitude that kept most Unix tools quite user-unfriendly for several decades. What information to show the user, and when, are important design decisions to make. Just dumping it all on the user and making them wade through it is not doing the user a favour. Thankfully newer tools seem to be better about this, which has brought the Unix shell forward by leaps, even if there's still ways to go. (You can still make a conscious design decision that the info needs to be all there, and git is one of tools where that's at least somewhat justifiable, but a lot of the time the attitude is more like in the quoted text, that dumping out more info is always better.)
CLI output should be in plain language and omit or minimize unnecessary detail absent a -verbose flag - for example, I'm just not interested in how many threads something took unless I'm working on it. As a user, I want to be focused on the task I'm doing, not on the perfromance of the tool.
I don't mean to be too glib, but some programmers have this decrepit idea that anyone working with computers should understand programming to be able to fully utilize them.
I worked in gamedev, and many of my colleagues were brilliant, but your comment would read as complete nonsense to many of them. That is the problem git has in the gamedev space. You're trying to manage teams of programmers, designers, sound engineers, gameplay specialists, producers...even c-levels. The parent comment to yours is right, to many many people who work on things that Lore could be useful for would find git to be gobblygook.
It also recreates a lot of the stupidity of mercurial (which makes sense)
The fact that everyone needs the same stupid “tug” alias because jj wants to use “bookmarks” instead of just named branches is just classic silly shit.
We’ve had named branches for 40 years. Everyone who has vcs experience knows what it is. We don’t need bookmarks. Just stop. Everyone who used mercurial used plugins to turn them into basically branches and same thing with jj.
'add' tells git to start tracking some file(s)
'commit' tells git to save the currently tracked files
'push' says "upload my changes to some other location." Git isn't dropbox magically 'rsync'ing the directory to some server.
'pull' says "download any changes from some other location." Same deal as push.
That should satisfy the majority of git casuals that get frustrated with it. You should learn the tools of your trade, and version control (specifically git) is one of the tools of the software trade. If you work adjacent to software why is it so hard to learn a little about git?
> I wish I could use a better code review tool than Swarm.
With one caveat. I think swarm is a great tool. It could do with being easier to configure, but as a code review tool it's simple, straightforward and gets the job done.
> I wish I could integrate SSO without weird LUA hooks which cause segfaults on my machine (enough of them causing a perforce deadlock).
this is about the only thing that Perforce has actually managed to do in the last... 5 years? [0] It's also woefully awkward to set up and operate, as is everything P4. But it does work.
[0] https://help.perforce.com/helix-core/integrations-plugins/he...
When I got more experience I finally understood why it is like that, and it makes sense now, but its still a lot of steps for someone learning to remember.
[0] https://en.wikipedia.org/wiki/List_of_minor_Star_Trek:_The_N...
It's more likely that they took advantage of some things in the license that you weren't aware of, since stealing would be illegal.
--flaunt-revision=<commit-graph> - Flaunt the revisions of extra commit IDs that are mirrorred.
~/work/tmp/repo git init . --quiet
~/work/tmp/repo master echo 'foo' > foo.txt
~/work/tmp/repo master? git add .
~/work/tmp/repo master+ git commit -m "create" --quiet
~/work/tmp/repo master mv foo.txt bar.txt # no `git mv`
~/work/tmp/repo master*? git add .
~/work/tmp/repo master+ git status --porcelain
R foo.txt -> bar.txt
~/work/tmp/repo master+ git commit -m "rename"
[master a06c680] rename
1 file changed, 0 insertions(+), 0 deletions(-)
rename foo.txt => bar.txt (100%)
Maybe lore does the same, but the docs imply that it doesn't.
--
To summarize: lore will record relationship metadata only when performed with `lore stage move <from> <to>`, so you will have to intervene if your other tooling moves files.
Plenty of not-very-granular "enterprise" systems out there, it's not exactly unique to not always have full ACLs on the smallest of objects.
Not exactly but if you're not obsessed with maintaining a monorepo, Gitlab allows you to organize your repos around organizations, which then has granular permissions. The underlying primitives is still Git, of course, so you can just submodule as necessary.
With the giant caveat that doing this effectively breaks the history of the parent project. TBF that's not really any different than rewriting history and later discovering that an old version of a lockfile no longer works but I still think it's worth mentioning.
I had previously worked on a big tech monorepo that has gigabytes of history. It would take forever to clone or do operations on. I had a cheat sheet of git commands that would do things lazily but I forget them (which is the issue).
Contributions from jvns:
https://github.com/search?q=repo%3Agit%2Fgit+jvns&type=commi...
Here she explains how she did it:
https://jvns.ca/blog/2026/01/08/a-data-model-for-git/
Contributions I've made:
https://github.com/search?q=repo%3Agit%2Fgit+jaysoffian+docu...
Generically:
https://github.com/search?q=repo%3Agit%2Fgit+documentation&t...
Do you have a link to your proposal on the git mailing list?
Keys, secrets, etc. yes. But code? What am I missing here?
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
This is a weak argument you could use for any missing feature.
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” component at read-time.
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 to complain about git...
The issue is what you and the above points out - it is not easy to read.
What might help dramatically is a simple modification of text (the verbose stuff could be slightly light grey and the important bits fully highlighted white) or even go full IRC with colored text, bold, etc.
Or hell - maybe instead they add a switch that inserts "//comment" like additionally lines to explain what is going on (succinctly) to the average Power User type. The default could be "software engineer" mode and the switch enable "Git for Dummies" mode.
I was simply answering niek_pas's rhetorical questions, that's all, because maybe they piqued someone's curiosity and I can contribute a little of my esoteric knowledge about the inner workings of git. This is a site for the curious, yes?
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.
Cheers.
Git is a software development tool first and foremost to support the development of an _operating system kernel_. It's perfectly reasonable for it to be technically verbose as a default, in the same way as it's reasonable for a band saw to cut off your finger if you use it without understanding things correctly first.
The problem git has in game development is not that the output is too complex, it's that it doesn't handle large binaries well (ironically enough, the focus of the replacement system in TFA).
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.
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.
Gitolite supports per-diectory/file write access natively, for gitlab you'd probably need to write your own.
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.
"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.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.
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.
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.
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.
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.
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.
Horde configurations can only live locally or in Perforce: https://dev.epicgames.com/documentation/unreal-engine/horde-...
Horde only supports Perforce today: https://dev.epicgames.com/documentation/unreal-engine/horde-...
UBA and Horde go together pretty well- in fact I've never seen a distributed-UBA deployment without a horde one (SN-DBS, Fastbuild or if you're wealthy: incredibuild are much more popular), but adaptive unity builds check for a read-only flag; which is how Perforce treats checked-out/changed files but not git.
C++ also lacks much of the fancy pattern matching features which are frequently associated with functional programming. Such features may not be fundamental to functional programming, but they would fall under "some functional programming features", in the sense that they're common in the languages of that ecosystem.
(Trek) Data is Lore constrained to, what? Convention?
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...
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.
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.
I'm just asking questions!
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.
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
git would be perfectly usable without knowing how many objects it has pushed or how fast it was doing so.
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).
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.
The point was that this bothered me when I used git for the very first time (what is it like 15 years ago at this point) and indeed did not understand it yet. Hope your comment made you feel better about yourself at least.
Swarm "works with it" in theory, but in practice I had to patch the loginWithSSO function to shell out to the p4 process to handle auth, because P4PHP doesn't expose ClientSSO at all and it's required for a clean login with keycloak.
EntraID is a different flow that they've probably nailed, from what I hear from other studios.
I feel like other commenters are being obtuse on purpose and avoid the point? Or did I just not word it correctly
Everything is so easy when your entire source repo is a paltry few hundred megs and you can build everything from source in a few minutes. It feels like flying.
[1] https://gitolite.com/gitolite/overview.html#what-is-gitolite
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.
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.
> Imagine typing cd folder
It's not comparable. `cd` is a local command (technically a shell built-in) that completes instantly (unless you cd to a hung NFS mount...). So it honors the Unix philosophy of emitting nothing on success.
But cloning is a network operation. And it's normal for networking tools to output progress by default. See `wget` and `curl`.
The problem with hiding progress under `--verbose` is that by the time you need the information (why is this taking so long?), it's too late to add `--verbose`. You'd have to cancel the command and run it again losing progress.
If you don't want it, then use `--quiet` and move on with your day.
(Sure you could make it smarter by deferring outputting anything until it realizes the operation is taking some time. Patches welcomed.)
No news is good news.
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.
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).
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.
Sort of. I add provenance, which helps properly identify collisions, and require a well-defined order by stacking [1] changelists.
> The doc claims it's the first with this technique.
More like the first with the particular angle on the technique. I specifically mention patch theory as another side of the same coin.
> A 30 second search reminded me of Darcs, and taught me about Pijul, and Weave.
Darcs is Pijul's ancestor, and I mentioned Pijul. I also mentioned the weave and how reference sets scale better.
> The example in the doc uses text, and unfortunately I think it's for a reason.
Readability. Nothing more. The real stuff will be a compact binary format.
> 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.
Yore will dedup change data instead because as the Lore document itself identifies, dedupping content is hard using chunks; you either get dedupping or canonical addresses. Change data doesn't have one canonical address; the address is in the commit data instead.
Dedupping changes has another benefit. If most instances are "replace A with B," and A replaces B in multiple places, Yore will be able to store just one instance of A, no matter its size. This matters because the larger the chunk, the less likely it will match any other chunk.
> 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.
True, but that should be table stakes. The fact that Git does not is a poor reflection on Git, not an innovation in Lore.
However, if you just move or rename a file, git does recognize that, and it doesn't require any manually annotation.
Lore needs you to tell it that you're moving or renaming. It's not the end of the world, but it's a real pain if other tools are operating on the file. You will need to go back and manually annotate those operations if you want it to preserve the relationships.
> The incident began Monday when ATI, which supplies graphics cards for all Apple's current models, issued a four-paragraph news release that stated its Radeon processor would be featured in three new Mac models -- none of which were announced by Apple (Nasdaq: AAPL) until CEO Steve Jobs' Wednesday morning keynote address.
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.
Right now, if you want to push a change to a file in a submodule such that it propagates to the users of your repo, you have to:
1. Change the file
2. Commit within the submodule
3. Push the submodule
4. add the submodule change in the outer repo
5. commit in the outer repo
6. push the outer repo
If you're making the point that there are multiple confounding factors to just about any non-trivial problem, then I agree.
1. They kept existing designs, since even Jobs wasn't so crazy as to demand a complete re-architecture of existing laptop models on a whim; plus they probably also had contractual obligations/pre-purchase arrangements
2. They switched to nvidia, but from everything I know they also hated working with nvidia (IIRC Jobs accused nvidia of stealing Pixar tech)
3. AMD is a different company than ATI (technically), and Apple of that era was different than the Steve Jobs temper tantrum era.
But yes, relevant details.
That's kinda a no-no for partnerships.
At least they gave us the `--porcelain` flag, meant exactly for this use case, to make the output format of porcelain commands never change. Dumb flag name, though.
Lore is clearly influence by 30 years of epic using perforce, and this is how P4 works.
Namely, his belief that CEO == company.
Jobs would never take the view that the action of the CEO of ATI is actually one bad actor acting alone which doesn't represent what ATI wants as an organization, and is unfair and damaging to that organization and all of its employees.
The reason he would not take that view is because then he would not be able to believe that he is the single most important thing at Apple, overshadowing everything else.
If the leak had been the responsibility of some rank and file employee at ATI, with appropriate action taken against that employee by the ATI CEO, it is likely that Jobs would likely have reacted differently, because it then would not longer be seen as a personal matter between him and the CEO, where the corporations are just pawns in a game of teach-you-a-lesson.
People use it everywhere here, just because its easier than carrying around a card.
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.