Show HN: Oak – Git replacement designed for agents

Show HN: Oak – Git replacement designed for agents(oak.space)

68 points by zdgeier 3 hours ago | 79 comments

Oak is a version control system I've been working on designed for agents (https://oak.space). It improves the speed and context your agents need when working on serious projects. With virtual mounts, agents locally and in the cloud no longer need a full copy of a repo to get working. You can work on many tasks in parallel without needing to download everything or fight worktrees. Version control shouldn't waste you or your agents time. It should be fast, creative and fun to make things with agents.

Oak is still early in development. There's no Windows build and missing plenty of features (no CI, no issues, no comments). We still use GitHub Actions for building Oak now, but we've been fully bootstrapped on Oak with no Git backup for several months: https://oak.space/oak/oak.

Blog post: https://oak.space/blog#git-is-forever

Docs: https://oak.space/docs

hnlmorg 51 minutes ago |

I have absolutely no idea what this offers that makes it better than git (or any over VCS for that matter) for agents.

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

zbowling 46 minutes ago | |

>the performance of git isn’t a bottleneck for agents.

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.

PunchyHamster 6 minutes ago | | |

checkout repo into tmpfs

kjuulh 1 hour ago |

I've built my own workflow for using agents on git, as i now often have to do changes across repositories, or in the same repository for different tasks. I could use worktrees, but I'd rather invert it, give agents the ability to have a workspace, that they pull repositories into, create branches as they want, commit on main it doesn't matter. the agents don't bother each other, and when i finally have to merge, conflicts are either resolved, or it is just smooth sailing.

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.

https://github.com/kjuulh/gitnow

zdgeier 1 hour ago | |

Looks awesome!

pixlmint 1 hour ago |

Did you have your agent talk you into making this something separate over building on top of git?

zdgeier 49 minutes ago | |

Haha I wish, but I've been working on VCS's separate from git for a while now. Although I do love git, I've wondered for years before agents if something could be made using something different, rather than building something on top.

zdgeier 47 minutes ago | | |

I'm also secretly a massive fan of Dr. Hipp and his work on FossilSCM [1]. I love a bunch of his design decisions there and wanted to apply them to a new system.

[1] https://fossil-scm.org

mohsen1 19 minutes ago |

The lazy mount is very interesting. This is similar to how google3 works at Google that I have not seen any similar implementation in open source so far.

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

coldstartops 31 minutes ago |

I am curious, how do you handle latency issues for on demand access? I saw you use FUSE (and FSKit), and from my experience it is pain to make filesystems in userspace work on-demand over WAN because a) latency, and variable RTT; and b) you can't saturate the wire and aggressively read ahead things, otherwise native apps will freeze, lag, or just make the UX unpleasant, especially if there are too many placeholder files, or large files with random jumps in them.

zdgeier 23 minutes ago | |

I think what makes FUSE/FSKit great here is that agents usually only need to see the file metadata + read a handful of actual files, rather than some applications needing read many things. If you're doing huge rewrites, this is a problem, but most tasks are usually somewhat small. Definitely is a problem that I've ran into though, we do cache aggressively to try to solve some of this, but it'll never be as fast as reading/writing directly to disk. We have benchmarks [1] if you want to take a look at how we're testing some of the performance there.

[1] https://oak.space/oak/benchmarks

CrzyLngPwd 45 minutes ago |

Back in the day, 2020, the effort to create a program/website/service was the prohibiting factor, which meant the sediment remained at the bottom of the barrel where it belonged.

Now, every brain fart is published as a finished product no one wanted.

pnw 36 minutes ago |

Zach is underselling his achievements here, having previously built the Jamhub VCS which was acquired by a well known founder.

blurbleblurble 18 minutes ago |

For concurrency reasons Pijul is an excellent git replacement for agents in my experience.

chadgpt3 2 hours ago |

> designed for your agents

And there we go.

ianm218 1 hour ago | |

> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.

From hacker news guidelines https://news.ycombinator.com/newsguidelines.html

ks2048 2 hours ago |

I would recommend just linking to a few sentences that say how Oak is different than Git, rather than a personal backstory. (https://oak.space/docs)

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.

dang 1 hour ago | |

Since many commenters had a variant of this response, I've turned the post into a Show HN above (more at https://news.ycombinator.com/item?id=48633408).

(The submitted title was "Git is forever. I'm building Oak anyways." and the submitted URL was https://oak.space/blog.)

zdgeier 1 hour ago | | |

Awesome, thanks! You could also change it to the homepage if you'd think that would work better for people. https://oak.space

sourdecor 2 hours ago |

I have always wanted a version control system that was basically Emacs/Vim/Neovim's undo-tree[0] but persistent and social. Why do I have to manually talk to git? You are a computer, track every modification I make while editing and let me decide (or help me decide) on what a checkpoint is.

[0]: https://i.sstatic.net/4vbd9.png

stouset 2 hours ago | |

Jujutsu might be what you’re looking for then.

LoganDark 2 hours ago | | |

Seconding Jujutsu! I've been working to add Jujutsu support to basically every open-source tool and framework I use, including the agentic ones [0]. While it doesn't work for everyone, I've found it can really work for some people. (like myself)

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.

[0]: https://github.com/LoganDark/get-shit-done/tree/jj-vcs

iknowstuff 1 hour ago | |

Zed’s DeltaDB is that very idea I believe

https://zed.dev/deltadb

Imustaskforhelp 1 hour ago | | |

is there some more information about DeltaDB? this seems to be an early access feature and not something available at the moment but I would be interested to learn more about it.

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.

robby1110 45 minutes ago |

Certainly an interesting project although I am wondering what makes the benefits mentioned agent specific? You have mentioned performance improvements which is great but in that case would it not just be a better vc than git in general? what perks only work with agents that wouldn't work with individuals?

zdgeier 35 minutes ago | |

Thank you! The bet we're making is that agents will need to work on tasks much faster and with more parallelism than humans do with Git right now so these performance metrics will matter more. Git is awesome for human work so I'm not sure these metrics really matter than much to people. But also for agents, worktrees are not the best (can't work on the same branch in multiple places) and also the speed at which branches/PRs are created, need to be merged, etc. will need to be way faster and simpler since keeping up-to-date with how fast things are being modified is really important.

weinzierl 2 hours ago |

"Git is forever"

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.

Pet_Ant 2 hours ago |

What I want from a version system is to capture event in history not like changes as a files but as events that capture a process.

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.

WolfeReader 2 hours ago | |

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

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.

packetlost 2 hours ago | | |

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

agalamli 1 hour ago |

seems like an interesting idea. the only friction would be to get people to use it instead of git, however i believe it will happen slowly, more people trying it and recommending it to others.

manquer 58 minutes ago | |

There are git clients for perforce, hg, svn and so on[1]. Oak' developer (or the community) could always develop a git frontend for users who prefer that .

[1] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-...

zdgeier 1 hour ago | |

Totally agree. This is going to be the hardest dev tool to get people to switch, but we're trying! I think there's going to be many more players in this space in the next year or so. It'll be interesting to see what shakes out.

achandlerwhite 2 hours ago |

Grammar nitpick: "anyways" should almost awlays be "anyway"

applfanboysbgon 2 hours ago | |

https://www.merriam-webster.com/dictionary/anyways

isodude 2 hours ago | |

"awlays" should almost always be "always"

GroksBarnacles 55 minutes ago |

I wish we as a society would stop using random words for products. "Slacked about Oak, but they need in Fizzle. The deck's in Slate, the assets are in Vault, the timeline's in Pulse, the copy's in Quill, the build's in Forge, and the launch party's already in Ember."

gitpusher 14 minutes ago | |

What alternative would you suggest? "Sent a message in our enterprise chat application about the version control system that our engineering team sometimes uses (no, not that one, the other one) but they need it in the project management app that our Design team uses (good luck requesting access from IT, we have more than a dozen project management tools in our catalog)"

IshKebab 2 hours ago |

Does this try to solve the biggest problems with Git: submodules and LFS?

zdgeier 2 hours ago | |

Planning on some monorepo features soon that should solve some submodule problems but haven't approached yet. I have some new ideas here. And yes, no separate LFS system!

IshKebab 2 hours ago | | |

> And yes, no separate LFS system!

Awesome. How does one decide which files should be stored externally, and manage that? And where is that decision stored?

jazz9k 1 hour ago |

It's kind of like replacing Wordpress. Sure, you can make a better alternative. But replacing an entrenched player that has been there for at least a decade will be almost impossible.

dgellow 1 hour ago | |

you don't need to replace, you just need to find your niche, then expand from there

vova_hn2 2 hours ago |

I cannot imagine git being a performance bottleneck in agentic workflow.

> 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"?

nixosbestos 2 hours ago |

Yeah, I'll just wait for jj to get more virtualized FS features, and be very, very happy with that.

zdgeier 31 minutes ago | |

I love jj! Martin is really awesome and love his work. I know they're using a VFS backing inside Google for their monorepo, wonder if we'll get some of those cool features on the outside.

noelwelsh 2 hours ago |

A few comments:

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

philipwhiuk 2 hours ago | |

"I built a version control system, in my free-time, called Jam" is fine.

AdamN 2 hours ago | | |

Just "I built a version control system called Jam". The free-time thing is good for a history page but the homepage needs to tell the important part (you've got history and expertise in this subject) and then move onto what the vision is for Oak and what kind of help you need.

stonogo 2 hours ago | | |

It's also fine without the commas, because nobody was confused by that structure.

sublinear 2 hours ago |

Lots of self-promotion, but no concrete comparisons where this tool does a better job than git.

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.

zdgeier 2 hours ago | |

Check out the homepage! https://oak.space might have what you're looking for. I can answer any questions you have here as well.

dang 1 hour ago | | |

Since this project hasn't appeared on HN before and is obviously of interest to people, I've taken the liberty of turning your post into a Show HN (which is the convention for sharing your work on Hacker News - https://news.ycombinator.com/showhn.html). I used the text from your blog post that explains what the project actually is - this is the bit we need to lead with, to stanch all the "I can't tell what this is" comments.

I hope this is ok! If you prefer different text at the top, let us know at hn@ycombinator.com.

manwithopinions 2 hours ago | |

The blog post is a terrible intro, the website is much more insightful: https://oak.space/

I found the section titled “Local feature branches. Server main. One squash.” most interesting.