Show HN: Oak – Git replacement designed for agents

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

Looks very interesting, but it's difficult to see the benefit from git right now apart from performance? Don't get me wrong, that's good, but I don't think it's a big enough proposition to get people to ditch git and move to oak.

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!

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

My impression with this space is that you'd need to fundraise startup-style, which I'm assuming you'll do, to catch up with everyone that is doing a similar thing.

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.

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

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

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.

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.

> designed for your agents

And there we go.

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.

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

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

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

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

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?

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.

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

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.

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

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

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.

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

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

[flagged]

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

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.