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.

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

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

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

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!

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.

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.

You kinda lost me there. I‘m supposed to use a central technology whose author can’t be arsed to write a few paragraphs?

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

    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

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.

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.

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.

Like replacing streets with rails while we claim FSD works out of the box

how does your agent run tests or click around the UI to verify changes if it doesn't have the full code?

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

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

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.

YAAS (yet another agentic substrate)

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.

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