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 mainThe 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 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.
There are 1000 things that's true of about git. At a certain point that becomes a problem in and of itself.
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.
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.
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?
The git support for new employees drops basically to zero.
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?4222dfabI’d be a bit worried if git didn’t heave that particular contented sigh when I ask it to push
Not saying Lore's approach is bad, but sometimes "worse is better".
Still the porcelain is more like cold stainless steel
Having this output is useful for when it does break and you need to copy-paste your terminal output to someone who does understand it to explain it to you or explain how to fix it, but you're correct that 90% of this is effectively debug output that is almost never useful or relevant.
In most cases I would say they should remove any output that isn't necessary, but given that some git operations can be extremely long-running it's beneficial to have some kind of output so the user knows what's going on.
Case in point, this is the output I get when I try to clone the Linux kernel:
Cloning into 'linux'...
remote: Enumerating objects: 11623749, done.
remote: Counting objects: 100% (396/396), done.
remote: Compressing objects: 100% (189/189), done.
Receiving objects: 1% (181683/11623749), 90.11 MiB | 19.17 MiB/s
Also, I assume you're not but in case anyone is interested in the answers to these questions:
> What the hell is "delta compression"?
The 'delta' is the difference between one thing and another - usually one version of a file and another. Git does some fancy thinking to figure out which files are which other files but with changes, so that it can store just the changes from one version to the next.
For example, a 100 KB file where we only changed 500 bytes ten times would be 1000 KB, but because Git can store the deltas from one to the next it can be 100 KB (the original) plus ten 500-byte changes, for a total of about 105 KB.
> Why do I care how many threads it's using?
Because it directly affects how fast the process works; using 16 threads is 16x faster than using 1 thread (on average). Git automatically detects how many CPU threads are available and uses as many as it can, but if it's being very slow you might look and see 'oh, right, this VM only has two CPUs'.
> What is an 'object' and what does it mean when it's 'local'?
Uh, this one is deliberately vague I guess. An object is a thing that Git keeps track of. Usually this will refer to a blob, which is 'a bunch of bytes that make up a file', or a 'tree', which is a list of files and other trees - basically a directory structure, or a commit's information, but anything that Git keeps track of is an object.
Local just means that you already have a copy on your system. in the 'remote:' line you see output from the other end (where you're pushing to), so that's the server saying that it's using the files it already has.
> What does 'pack-reused' mean?
To be efficient, Git can take all the 'objects' and smush them into one big packfile (rather than having to keep track of hundreds or thousands of separate files). Since Git keeps track of files based on their contents, two identical files are just stored as one copy referenced twice, so it's possible that the file that you're pushing already exists in a pack file and can just be reused rather than having to push another copy.
Perforce 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.)
>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.
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.
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.
I'm not just picking nits here. And this is not cynicism.
so there you go.
[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.
- 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!
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/
> 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"
That would be very powerful for various use cases.
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 push[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.
It also makes diffing hard, as well as diff viewing.
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.
I 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
Passing for now.
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
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.
Helpful page that gets closer to the details
[0] https://github.com/EpicGames/lore/tree/main/docs/developing/...
[1] https://github.com/EpicGames/lore/blob/main/docs/developing/...
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?
Count on it.
From the horses mouth itself:
https://x.com/timsweeneyepic/status/964284402741149698?lang=...
He straight up makes fun of Linux because he hates Valve and GabeN.
https://x.com/TimSweeneyEpic/status/2054680825677910439?s=20
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?))
Its remarkable that anyone thought this website was fit for release, and it gives off strong slop vibes
I also have absolutely zero trust in a product like version control being provided by a for-profit company. It seems like a terrible idea to tie your software stack to Epic Games of all people, given their track record
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.
Code forges lead to the next reason -> they are making it open source (see the faq for why). If they want community collaboration it makes sense to prefer industry standard tooling. Organization internal consistency doesn't matter to external collaborators. Various Google projects with all their custom tooling are good example of what happens if this gets ignored. Every time I have to deal with depot_tools or repo it's a pain.
Third reason not to self host is that it's not quite production ready (see "Is lore production-ready?" in the FAQ). Can't be self hosting from day 0 and once you have a working setup you need better argument for switching just because you can. If lore was attempting to make a statement that it's a superior method of version control for regular source code it would be a different story.
It’s like anything you do has to talk to the server
Even something as simple as diffing a file will just hang if there are server issues
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.
> 3.2 Explicit non-goals¶
> Peer-to-peer decentralization. Lore is centralized by design. Two clients communicate through the remote, not directly.
It is interesting that people are so cynical about Epic giving out free games. I get that people love Steam, but competition in the storefront market is not bad.
It's a mischaracterization to call the games free, if 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). In that sense, you may see it as backlash around characterizing the games as free in the first place, when they obviously are not.
Would love any feedback on it or contributions if people are interested :)
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.
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.
Keys, secrets, etc. yes. But code? What am I missing here?
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...
> 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.
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.
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.
That is partially incorrect; you can restrict writes via hooks but not reads; you'd need a workaround like submodules
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.
Unfortunately there are many people who think git is a panacea and is suitable for all version control tasks of anything.
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.
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.
Git is bad at such volumes of binary assets, textures, models, sounds, etc.
[1] https://github.com/debarshibasak/assets
1. Code - Git
2. WIP art, shared assets (logos, marketing materials, etc) - Google Drive (because things are often changing, getting passed around, etc)
3. Finished assets (PSD files you're done with, or you think you're done with) - SVN (because we wanted a log of who contributed to what, wanted artists to be able to pick up where someone else left off; having a log of who made changes to a given PSD)
4. Assets rendered out to PNG to include in the app bundle/publish to the static file servers - Git (because those files never changed after being published so the git history wasn't polluted with unneeded files)
I've also used LFS, which is... a fine workaround, but still not great. Users who don't have it configured can still commit binary blobs; users who don't have it configured will clone files incorrectly; if the LFS server is slow, unavailable, unreliable, then the system starts to behave oddly; you need a Git server that supports it.
It was a huge hassle to manage; having a system like this would have been a godsend at that company, and if I still worked there I would be spending all day importing our codebase and assets into it to see how well it works.
SVN makes sense cuz it's done and dusted, but I could see the Drive gettin real messy real fast if things change a lot
In fairness, p4 predates most of the VCSes we consider "modern", so I empathize with a lot of the underlying architecture decisions. However, it has and continues to utterly fail at improving at a reasonable pace.
For example:
p4 also significantly predates VCSes we consider obsolete. p4 is almost a decade older than SVN.
- The P4 cpp api was apparently designed before any modern Cpp std lib was available. And is at best archaic, and stringly to use.
- P4 encoding support is pain in the ass to configure. And ensist on adding or removing bom to files.
Git-annex ?
If perforce is the best there is out there for large binary asset management, then there is a blue ocean worth of potential improvement for git.
Perforce is a piece of crap, a relic of the 20th century that must die in a fiery inferno.
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.
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)
* https://github.com/jj-vcs/jj
* https://nest.pijul.com/pijul/pijul
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.
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 think being influential just does that to people, with high regularity.
Huge teams are more often than not the sign of bloat and inefficiences.
1. https://www.angelcode.com/products/bmfont/
Now there's an argument to be made that many don't need the remaining ones but to claim that you 'replaced PowerPoint' for anyone but yourself is ridiculous.
They're good at demos, I give them that.
I'm wondering if you're confusing Windows terminal with cmd.exe?
Windows terminal is not the shell. It's a terminal emulator. You run a shell inside of the terminal, for example you can run... Powershell.
Command history is a feature of the shell.
https://epicgames.github.io/lore/explanation/system-design/#...
If this supports dynamic hydration of files, either as they're accessed (like Dropbox with offline files) or by somehow knowing which files need which other files (building a dependency graph) then it could be a massive win both for speed and efficiency of downloads but also for conserving disk space on developer machines.
And since it has API bindings, it's possible that's something that could be built into IDE plugins, so that your editor (Godot, Unity, etc) can know which assets need which other assets and automatically trigger hydration, including when you e.g. try to use a new model/texture/etc in a scene that hasn't used it yet.
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).
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.
At Fortinet we migrated our SVN repositories to git and ran into a ton of issues; developers over the past ten years had done tons of little mistakes that added up, like accidentally checking an entire Windows virtual machine into the repo. In SVN they deleted it and no one ended up caring, but in Git of course it became part of the repo history.
I did a huge amount of work for the migration, 99% of which was analyzing each repo to find out what files/file extensions were overly large, and then either:
1. Filtering them out of the git history completely during import
2. Converting them to LFS objects after the import
The LFS process was certainly better than the other alternatives, which were 'check everything into the git history' or 'remove all the un-diffable binary files and hope that they weren't needed for anything', but it was still not ideal.
Every developer (out of thousands, across multiple countries, timezones, and native languages) had to set their system up properly; if you missed a command, or if you reinstalled your OS and forgot to set up one of the aliases or hooks, then you would end up checking binary blobs into git rather than LFS, or checking out LFS idents rather than the actual files they needed.
We also had the issue of developers fetching code over SSH but LFS files over HTTPS, which would be fine except that we wanted to prevent access to HTTPS from most subnets, so while the developers could use SSH to clone or pull using their 2FA token their client would then make an HTTP request that wouldn't work unless they were on the version control VPN, which.... blah blah blah.
So yeah, it worked better than the alternative, but it did not work _well_ a lot of the time.
it's also tough when you have 1TB of data, over 1mm files and you might want to lock hundreds files in one go
I think branching is the one thing that didn't get more complicated with LFS.