zdgeier

Do you think it's possible in the next few years or so that agents will improve to the point that some of approval work can be offloaded to them?

True, I do wonder if we focused more on the parallelism aspect with mounts that it would resonate with people more. Thanks for the thoughts!

It's also made for humans as well :) We have some nice TUI stuff in the CLI that you might like. Check it out if you're curious and let me know if you have any thoughts.

Agents in the cloud (and locally) need to have a full repo, even if they only need a small percentage of a repo to make a change. You can also imagine if changes are being made in the cloud by multiple agents, each one of these agents need a shallow clone at the very least. If you're spinning up many agents in the cloud this becomes a bottleneck. So not really that downloading things is a bottleneck, it's that agents need to download way less to make the same decisions and changes.

Mostly through networked file system mounts with FSKit/FUSE backing when working on tasks in parallel. May be applicable for human facing tools but I think workflows there are already pretty set with having files locally and mounts need some lifecycles that agents are probably better at handling.

Happy to describe or answer questions here. It's a version control system (like Git/GitHub) designed for agents. Some specific things that make it different than git are a simplified branching system and networked mounts so you can work on tasks on a repo in parallel.

I do think hosting is an important part of the VCS story. I agree that hg and jj and sapling are capable of being front ends to a google3 like backend GitHub like thing to support it (Google has this internally for jj). Of course some people are working on hosting solutions for these but it feels wrong to me that hosting platforms and their underlying VCS are not made by the same team. IMO people like google3 so much because it’s one integrated system which is the approach I’m trying with Oak.

A good tingle or bad tingle? haha

Good question, the files are grabbed on demand from the server so the agent can fetch everything it needs to run tests, a dev server, or anything it does normally. Now this might be slightly slower in some cases where the history is short, but the bigger the repo and files the more this makes sense. So the full code is available and buildable, just over the network instead of locally.

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.

I do wonder how far you can make git work like google3. Partially why I'm making Oak is because I think it might be hard to impossible to implement the necessary features for monorepos to work correctly in Git. I don't doubt that it can be done, I do wonder how it will feel though.

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.

"download everything" means that you don't have to do a full or partial clone of the repo to make a change. You can imagine agents running in the cloud need to spin up and access the repo for every task, this can be slow for large repos (also small repos with large files). Also locally, worktrees can be a pain to manage with conflicts, confusing branching, and you can't check out the same branch multiple times. But I do agree that we're probably still pretty early on in the agentic adoption that many users using agents in git-like ways will not see much performance improvement.

Could probably build a Git backend at some point for people to use kind of like how jj does it. Right now my goal with this is to see what's possible natively if we don't try to build on top of Git. But definitely agree that the wording needs to be improved here to explain what benefits we get from not building on git (better mounts, built-in LFS, clearer branching/workflows, etc.).

Great point, the readme for this repo is not great right now and we have a bunch to improve on that people have pointed out. Thanks!

Actually this https://news.ycombinator.com/item?id=34439461 contains some great discussion about JamHub if people are curious. I changed the name from jamsync to jamhub. :)

Partially why I got so excited about version control is how well this post blew up when I posted.

Definitely agree and great points. This is going to be a very busy space in the next year. haha I've never used ClearCase but my friend told me about mounting VOBs in ClearCase so I'm excited it bring it back. Thanks for your thoughts!

Agree we should definitely support offline flow. You can download the binary manually if you would like [1]. Although the offline/self-hosted flow isn't fully tested right now, would love some feedback on it if you're able to check it out!

[1] https://github.com/oakdotspace/oak/releases

Totally agree with everything. Definitely will be hard to get people to switch. Also love the monorepo idea you mentioned. It should totally be possible to keep the benefits of a monorepo without the downsides of git submodules. So you should be able to open-source parts of a repo without open sourcing the whole thing. One of the benefits of building from scratch is that this is pretty straightforward. Also the other ideas you mentioned are really awesome. Thanks!

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

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.

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.

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

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.

Yes Lore looks awesome! I was previously working on a VCS for gamedevs -- that space definitely needs something better than Perforce haha. My comment would be that I think you need to nail a new GitHub + Git to really be successful in the space and I'm not sure Epic is focused on this. I wonder if Lore will turn out similar to Unity Version Control which is very specialized to Unity workflows or something more general. Definitely love what they're doing though.

Sick, looks great!

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

Looks awesome!

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.

I'm a little confused by this but I assume you're talking about marking files for LFS (.gitattributes)? For us, we chunk every file (even if it's a single chunk) so every file is stored in the same way -- it's just data to us. But let me know if I got your question wrong.

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