Models know git because there's a monstrous amount of git in their training data. Models never heard of a new thing "for agents", so you have to teach them to use it via skills and docs. Models can, of course, follow documentation, so there's nothing stopping them from using the new thing...but, the new thing "for agents" starts the race well behind the known thing that was built for humans a decade or two ago and has huge amounts of training data baked into every model.
I'm not saying nobody should make new things (an accusation I've gotten when saying something similar about a previous "for agents" thing), of course people should make new things. I'm saying that when I see "for agents", I think, "prove it". Agents don't have trouble with git, so there's gotta be some kind of pain point about using git with agents that I'm unaware of that this solves somehow (but isn't expressed on the page) or this isn't actually for agents, it's just a project someone wanted to do (and that's also fine!). But, if the latter, "for agents" is merely marketing and I'm not interested.
When I say "benchmark the query engine using the foobar dataset and compare it to run 431", the agents go and run my special benchmark tool and use the different subcommands to compare results and so on.
I'm sure a new VCS would be a little less smooth sailing, but not by much.
I highly doubt that your tool is like this:
> git branch -vv | grep ': gone]'| grep -v "*" | awk '{ print $1; }' | xargs -r git branch -d
Or:
> ffmpeg -i main_course.mp4 -i reaction_cam.mov \ -filter_complex \ "[1:v]scale=480:270[pip_scaled]; \ [0:v][pip_scaled]overlay=W-w-20:20[pip_video]; \ [pip_video]drawtext=text='LIVE RECORDING':fontcolor=white:fontsize=24:box=1:boxcolor=black@0.6:x=30:y=30[final_video]; \ [0:a][1:a]amix=inputs=2:duration=first:dropout_transition=2[final_audio]" \ -map "[final_video]" -map "[final_audio]" \ -c:v libx264 -crf 21 -preset fast \ -c:a aac -b:a 192k \ output_production.mp4
LLMs generate these for breakfast.
The crazy thing to me is that this kind of “composition of small tools to create something bigger” is the biggest vindication of the Unix philosophy I can think of.
I have to wonder how much of that behavior was trained into the model and how much it is the secret herbs and spices they toss into the harnesses own system prompts.
There are work arounds though and I am creating what I call knowledge triggers for Pi that are similar to claude's "PreToolUse" so having the agent use oak all the time is not an issue in my opinion.
The challenge for oak is why? Considering how I actually want to slow agents down so I can ensure it is doing the right thing and because the massive bottle kneck is the LLM themselves, speed when measured in milliseconds or even seconds will not concern many.
I thought oak was more of, we know how to prompt inject context based on code that is stored in oak for example, but faster operations can help, but the use case is limited. The missing piece for better/correct code is context at the right time.
There's a limit of how many simultaneous instructions an agent can follow (the exact number depends on the specific model so instructions that are fine for one model may overwhelm another). If this keeps happening, consider trimming your instructions or even better, solving it at the harness level (like intercepting and rewriting ripgrep calls to use your thing, like rtk [0] does in agents that supports this)
Overall, never leave to an agent an instruction that must be followed at all times. For example, doing things in a git hook beats a multi-command workflow every time the agent commit, etc.
Is this state of things forever? I don't think so. Very soon models will become so better this will be a non-problem
In the end, it became heavy overengineering: people no longer understood not only the repo itself, but also the extra layer describing it. Meanwhile, coding assistants are already quite good at reading codebases directly.
Sounds like a good optimization to me. VCS is a waste of tokens for sure. I’m intrigued to hear more.
Another option: when model invokes standard tool, rewrite the invocation to newfangled tool.
Bunch of ways of doing it:
(a) Invocation of standard tool returns error saying to use newfangled tool instead
(b) Invocation of standard tool returns message saying it has been dynamically rewritten to invoke newfangled tool, followed by newfangled tool output
(c) Invocation of standard tool in context is dynamically rewritten to invocation of newfangled tool, prior to execution
In case (c), the model ends up thinking it somehow knew about this new thing all along, even though it actually didn’t
Regardless, in any of these cases, the implementation for any of these above options may be vastly superior to the “naive” implementation for agents — but then the parent comment here is right that an engineer would need to justify their implementation to users, not just make a loud conjecture. It’s a non-trivial claim to say that a bespoke solution not present in tool-use training and accounting for context-rot would result in a better performing model. Moreover, justifying an agent-specific efficiency gain that humans wouldn’t benefit from makes the claim even more non-trivial. Using Sagan’s razor, it’s then reasonable for people to ask for a comparably non-trivial amount of evidence.
The thing we’re trying to optimize is not whether an agent can remember the command. It’s the runtime shape of agent-driven development.
When an agent drives a VCS through a captured terminal, things that are tolerable for humans become direct costs: clone/setup time, worktree setup, full status output, huge diffs, branch cleanup, interactive prompts, shared-checkout mutation, repeated preflight checks. Those costs show up as wall time, bytes over the wire, transcript tokens, and recovery steps.
So the Oak bet is narrower than “agents can’t use git.” They can. The bet is that if you assume branch-per-agent workflows, lots of parallel sandboxes, large repos, and non-interactive command execution, the VCS interface should have different defaults if you want to optimize for shipping speed and efficiency of token usage. If you're already going fast enough and not running out of tokens - then using oak seems pretty silly.
People do not need to ditch git to try Oak out. One workflow we care about is letting agents work in Oak where the agent-specific costs matter, then exporting back to git for the human review, CI, release, or compliance workflows.
Totally agree this should be provable and benchmarked. The homepage has Oak vs Git numbers because we do not want “for agents” to just be vibes. We’re measuring transcript bytes, estimated tokens, tool calls, wall time, large diff/status behavior, and contention in agent-style workflows. We’re also working on the benchmarks repo in the open: https://oak.space/oak/benchmarks
The exciting part to me is that we can already improve on tokens and timing despite starting with the model-prior deficit you’re describing. If we can win on measured agent workflows while git still has the advantage of being deeply baked into the models, I’m incredibly bullish on where Oak can get to as the tool and the ecosystem matures.
Longer term, if Oak proves useful and sticks around, future frontier models will likely have more Oak examples in training data, which lowers the upfront learning tax for an extra boost.
The tool is called gitnow. it is honestly quite simple, just create a project, add the repositories you want and get to building. I've found having another claude chat or whatever use the tool to great success coupled with zellij, but could also be zed, tmux or whatever.
Secondly it also pretty much solves the problem of the agent dumping memory files everywhere, they now basically have a scratch space that is theirs, where they can keep their tasks, and just update the repositories as needed.
Use gn the shell after eval if you use it, it will actually invoke cd, instead of creating a subshell.
There’s some mention about performance, which is great, but the performance of git isn’t a bottleneck for agents.
There’s some mention about token use being reduced, which is great, but how have they achieved that vs gits porcelain modes. And why does token count require a whole new VCS, and thus incompatibilities with all the established git ecosystems?
I really want to find reasons to like this but it’s probably some of the worst product marketing I’ve seen. And something this significant really does need to sell itself hard if you’re going to get enough people in a project team to agree to switch away from git
Edit: I see people bringing up lazy file checkouts in conjunction with mounting a branch. For some of the enormous repos people work in this makes sense to me.
Would this be like `git commit --allow-empty-message`?
But why? Why would I want to like a project which seems to invent problems rather than solve any? I don’t want to like this.
Eh, it depends on the workflow. Especially if you have certain stack based workflows. Worktrees are kinda half solution here but depending on the repo type and if you are dealing with LFS or sparse checkouts, I've had agents struggle really hard to work through a stack or rebase things without a lot of thrashing or being IO bound by just stumbling into operations in a boneheaded way. Now I have AGENTS.md/skills/hooks gaurdrails littered about to try and work around things.
I know git (the VCS) can become a bottleneck with massive monorepos at the scale of Linux or Microsoft. But is anyone likely to port them to something new just to be a little more agent friendly? And if the goal of this new VCS was to make life easier for large monorepos (for humans as well as agents) then why doesn’t the author mention that on the project’s website? Because that’s exactly the kind of thing that might make this an easier sell to project teams.
I would normally assume there's 0 percent chance that `git` (the binary) is a significant impact on LLM based devel. The same applies to git, the protocol/format/tree.
I'd love to hear about what makes the workflow you have, where any part of git becomes a noticable proportion of the process? Unless you mean your LLM just can't figure out how to use git?
Git sparse checkout is helpful but checking files out as they are needed is much more flexible and intuitive.
Microsoft VFS for Git / GVFS is the closest that I can think of.
There is room for this lazy mount idea to be built on top of Git
But of course at Google the file system part (CitC) is a layer beneath the version control system and is shared across different vcs tools.
Since it's early, here a couple of things I'd loooove git to be and it's not, maybe you can consider to go in this direction and, if there are many more like me, get a large user base: - The private/public quantum shouldn't be a repo but something more fluid within a repo. A public repo should be able to have private sub-directories, files, etc. If should be fluid in this regard, so big projects could open-source <i>some</i> features, not all. Right now it's all or nothing, and that closes the doors to many big closed projects. - env variables. If you could make its usage easier and more seamless within oak, that could convince many (me included). It's really a headache to deal with env vars and git, and shouldn't be the case. - Collaboration for agents beyond PRs. I don't know exactly what's the flavor for this, but I know that fundamentally the create PR/merge circle of git is not how it should be.
Great initiative and good luck!
Show HN: Open-source version control for game developers - https://news.ycombinator.com/item?id=36485377 - June 2023 (0 comments)
(Hopefully we're making up for it with this one)
Edit: ah here we go: Show HN: A version control system based on rsync - https://news.ycombinator.com/item?id=34439461 - Jan 2023 (118 comments)
Partially why I got so excited about version control is how well this post blew up when I posted.
Human decision-making, communications and awareness are the key bottlenecks, not code generation and commit speed, by several orders of magnitude.
And I think that's a good thing if we want to avoid mass-psychosis.
You kinda lost me there. I‘m supposed to use a central technology whose author can’t be arsed to write a few paragraphs?
My initial reaction is if this is not something than could be built on top of Git, rather than replacing it. Describe the data model - what is a "commit", what is a "branch" ..., if the same as git, then why not reuse.
(The submitted title was "Git is forever. I'm building Oak anyways." and the submitted URL was https://oak.space/blog.)
It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have to think at all about the stuff I hate about git (babying the index, being careful to amend and etc. right the first time because undos are annoying, etc.)
Does not support LFS or submodules though.
We still use submodules in a number of places at work so it’s a bit of friction for me. Other than that, I’m rapidly becoming a jj convert.
It actually works quite well and has never caused me any issues. I tried symlinking but that does not work, git doesn't like the .git being a symlink.
Relatedly, when I use filesystem paths as remotes they need to be colocated or else it doesn't work, which is a little annoying!
Edit: this was actually announced at a very recent blog post (11 july 2026 so just 11 days ago): https://zed.dev/blog/introducing-deltadb
The blogpost also has some more relevant information as well.
The problem space and solution has been around for a while in big tech, and now there is a handful known products publicly known, and probably a couple dozen still secret ones. It is just now with AI/agents volume, there probably needs to be an easier solution for quick narrowly focused VCS views.
For filesystem mount, usually FUSE-FS, of a version control system to enable multiple viewers without transferring a lot of data see some current/previous implementations:
- Google: Piper via CitC (Clients in the Cloud) often used with Cider (web IDE)
- Meta: Sapling on EdenFS (from what I read, never worked there)
- Rational Clearcase, anyone else remember mounting VOBs?
The main issue I see is with the site -- it just seems like a big blob of AI-generated text I need to understand what is going on. The cool part wasn't even shown off: your GitHub UI clone that you can get to from seeing the benchmark code.
FYI, I also think the 4-way arrows logo has been used before, and still might be in use. I tried searching, but I think I saw a multi-colored one, maybe in a UK-based IT corporate training company's class I attended.
This looks interesting regardless, but I do wonder if the latency focus is the wrong way to sell this.
Setup: a Linux box on the other side of Romania (compared to where I am living) reading from a Windows box in Singapore (~200 ms RTT)
- reading 1 MiB of a 1 GB remote file pulls only 16 MiB (~98% avoided) - this is because of my fine tuning optimization choice - first byte approx: 2.3s - git-LFS repos also clone cold over the mount byte-perfect (separate Mac - Linux run on a ~20 ms RTT)
The thing that I do differently is that my metadata is eagerly pushed, as I optimized for content streaming.
And 100k-file tree mounts I did not test yet.
But my goal was to have instant file access for generic files between apps, and peer to peer, supports also Windows :D
here is the tool: https://github.com/KeibiSoft/KeibiDrop
From hacker news guidelines https://news.ycombinator.com/newsguidelines.html
If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes. I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file.
Just a more human centric perspective on change history where it captures the way we talk and think about changes.
Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas.
"If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes."
Now this is a good idea that I've never seen in a VCS.
There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity.
I'd settle for searching the git history for a particular regex/string and then running a blame on that.
2) language sensitive version control seems like the next thing. We need like an LSP for VCSes.
`git split`
Something that I enjoy with jujutsu is that the semantics is the tool itself. ONCE you do that, the rest become easier!
how does your agent run tests or click around the UI to verify changes if it doesn't have the full code?
Another thing, inside these mounts build artifacts and directories like node_modules can act kinda weird, so we just have some extra context in the AGENTS.md to host these in a different location from the mount. or agents usually figure this out on their own in my experience.
Many things were forever until they suddenly died, but I think this is especially true for git.
I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.
There's plenty of workarounds too, but that's what they are. Workarounds.
With other backends, it inherits their problems. But also their solutions :) So with those backends, it could!
2. rebase based merge strategies - our team has 50+ devs across three continents merging into monorepo with teams maintaining submodules. By the time your merge request passes CI it has to be rebased. People are literally holding off on reviewing merge requests to make sure their own changes get in first
3. permissions for subdirectories/assets. some necessary code/modules are highly regulated and company secrets. Git cant lock certain directories based on who clones the repo
4. Agentic coding - if you don't commit then your changeset after each request is lost. JJ solves this. You could just say to commit after every request then squash the commits. But, I think this is an ergonomic argument
5. Maybe it's just my experience, but git-lfs is pretty annoying to manage on large teams and changing files to/from lfs. often easier to just delete and clone again
6. git blame on non-meaninful changes. Running a code linter to add/remove whitespace makes git blame return who ran the linter rather than who wrote the code
7. self-reported identity. every time we get new laptops (because they buy the cheapest POS) devs forget what they set for 'username'. so it ends up being 3-4 different identities with the same email
Those are just my complaints lately
2. That has the smells of a wrong code architecture. If change request leads to unneeded code conflicts, you need to rework your code architecture.
3. That’s valid, but why not create libraries out of those modules?
4. Valid. But I think the issue is on the agent side. Git has already all the features to make those happen, it’s the agent that is not integrated with git.
5…
6. Either than sweeping changes (adding a formatter, changing config,…) There’s no need for formatting changes to be its own commit in the main repo. I usually add a check to prevent inconsistent formatting.
7. The git history has the previous username and email recorded alongside each commit.
(Compare to Mercurial, Fossil or Git; those systems have consistent and usable interfaces. There's much less demand for wrappers or LLM tooling since they're easy to use already.)
2. Preservation of history. Two common commands - git rebate and git push -f - cause commit history to be lost, sometimes permanently. ("Just be careful" and "Just don't use those commands" are useful pieces of advice for an individual, and virtually impossible to enforce over groups.)
3. Conflict resolution. Git forces the user to resolve conflicts ASAP so we often lose information about A. What the conflict exactly was, and B. How the individual resolved it. Most VCS have this issue; JJ allows you to commit the conflict and solve it in a separate commit, which is nice.
2. https://git-scm.com/docs/git-reflog
It’s very hard to loose data in git.
3. The goal of writing code is to have working software. Conflict messages are like compiler warnings, better have them than getting errors slipping by unnoticed. If A conflict with B, the root cause is often a design conflict, which means that the design of the software is inconsistent.
The conflict only matters as long as it’s not been solved. For each commit, the design of the software need to be consistent, and the succession of commit describe the evolution of the design. A is not lost, B is not lost in the case of a merge and may stay for a long time when rebasing. C which solves the difference between A and B (and may replace B) is also consistent. I don’t care about inconsistency.
* monorepo megarepos - but you kinda need system built from scratch that sacrifices a lot in other places to handle that in the first place * media asset heavy repositories - again, different paradigm. Stuff that make Git great like full local history just become impossible to do sensibly when amount of changes per day is hundreds of megabytes.
Most projects don't git that. And for majority git + LFS is enough.
> This repo was written almost entirely using AI with human oversight. If you see anything that needs fixed or would like to contribute, please email ... or reach out on Discord
Why not just provide an email address that's delivered directly to the agents you have developing Oak?
I didn't delve into the benchmark repo to understand what your loop is measuring. Why would an agent (without fine tuning or oak-specific context) be faster with oak than it is with git or jj?
A large part comes from mounts. Being able to use FSKit/FUSE to make a change to a repo rather than doing a partial/full clone. A smaller part comes from having optimized context (json output) that agents are able to parse better with less tokens.
> You can work on many tasks in parallel without needing to download everything or fight worktrees.
What does "download everything" even mean? Why would you "fight worktrees"?
That said, it hasn't been enough of an issue for me to want to fix.
I thought I wouldn’t because it’s just another git - but git worktrees are a PITA.
Can I suggest though to focus the readme on the lighting fast checkout for multi agent loads? That seems to be the big selling point and is the real win over git.
I think other commenters here are missing the point - it’s not “for agents” in that the API is somehow agent friendly. Of course git being omnipresent in the training data gives it a one-up. It’s “for agents” in that it aligns with a multi-checkout workflow better than git does.
Now, every brain fart is published as a finished product no one wanted.
With AI, I can finally build what I've been dreaming about.
This is not the first "agentic VCS" project which claims both N% VCS token savings, and "faster VCS operations". But how are either of these two things a bottleneck? No case is made for this.
It dramatically improves the speed and context your agents need when working on serious projects: 50% fewer VCS-related tokens and 90% faster per operation.
"Agents locally and in the cloud no longer need a full copy of a repo to get working" - but was that ever a problem? And git supports shallow clones anyway.
work on many tasks in parallel without needing to download everything or fight worktrees
Awesome. How does one decide which files should be stored externally, and manage that? And where is that decision stored?
LFS "solves" those but it does it really badly. Really really badly. I've probably forgotten all the ways, but at least:
1. It conflates the content with the storage mechanism. You can't change retrospectively how the files are stored, even though the only thing you really need to be immutable is their content.
2. It requires you to actively set up git-lfs, otherwise it silently does the wrong thing.
3. Not exactly LFS's fault but I have yet to find a forge (GitHub, Gitlab etc.) which exposes the LFS stored files in a sane way. Last time I tried it was basically impossible to delete old files, and you needed a lot of extra work to even enable LFS in the place.
https://epicgames.github.io/lore/explanation/system-design/ if not
[1] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-...
Like replacing streets with rails while we claim FSD works out of the box
YAAS (yet another agentic substrate)
* The core idea sounds interesting. Make it the first paragraph, not paragraph seven.
* Spend more words describing what makes Oak different.
* "I built a version control system in my free-time called Jam". You probably didn't name your free time. "I built a version control system, called Jam, in my free time."
The only thing to go on is this single sentence: "With virtual mounts, agents locally and in the cloud no longer need a full copy of a repo to get working."
> For the first 100 users that subscribe to a paid plan I will send you a personalized e-ink display
I don't understand anyone who feels incentivized by this. Brogrammer 2.0 is weird.
I hope this is ok! If you prefer different text at the top, let us know at hn@ycombinator.com.
I found the section titled “Local feature branches. Server main. One squash.” most interesting.