Live data from Hacker News

Show HN: Oak – Git alternative designed for agents

oak.space

111–120 of 216 posts

Re: Show HN: Oak – Git alternative designed for agents

#111
post #71
post #70

Earlier quoted context omitted.

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.

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

I get pi.dev AI agents to use Fossil-SCM with a skill. Lots of built-in features like Wiki and Tech Notes. I’m sure there’s lots more to use with agents.

Re: Show HN: Oak – Git alternative designed for agents

#112

Anything "for agents" needs to provide some kind of evidence it's better than what the agents already have baked into the model training data. It can't just be "easier" on some dimension, because the model has already learned the hard parts of the old thing and models can't make new memories to learn new things, so there is always a context cost for the new thing. Models know git because there's a monstrous amount of…

Totally correct on the burden of proof here. Agents DO know git extremely well. There’s a huge amount of git in model training data, and anything new starts behind because you have to teach the model what it is, what commands to run, and where the sharp edges are. For us “for agents” does not mean “new syntax that we hope agents can read docs for.”

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.

Re: Show HN: Oak – Git alternative designed for agents

#113
post #24

Earlier quoted context omitted.

Git is great but if you really haven't found any reasons then you haven't looked at all. From large files to sub modules to hook permissions and file permissions... The list goes on and on about what where git falls short. There's plenty of workarounds too, but that's what they are. Workarounds.

Do you know if Jujutsu addresses these issues?

With the git backend, jj inherits git's problems. So right now, it does not, at least directly.

With other backends, it inherits their problems. But also their solutions :) So with those backends, it could!

Re: Show HN: Oak – Git alternative designed for agents

#114
post #79

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

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.

There is a Google intern project to work on an open source vfs thing, we'll see how it goes.

Re: Show HN: Oak – Git alternative designed for agents

#116

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 solu…

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!

Re: Show HN: Oak – Git alternative designed for agents

#117
post #76

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

Hmm - of course I went looking for the past HN discussion and it seems there wasn't one - that's a bummer:

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)

Re: Show HN: Oak – Git alternative designed for agents

#118
I actually like this.

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.

Post reply on HN