Live data from Hacker News

Show HN: Oak – Git alternative designed for agents

oak.space

181–190 of 216 posts

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

#186

Wait, I clicked and read, but I still don't know what is this about!

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.

Sounds good, but isn't that too little to justify moving out of git? Why couldn't this be written on top of git?

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

#187
post #134

Earlier quoted context omitted.

The main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it

What’s wrong with worktrees? To me that is exactly what mounting a branch would be. I use them a fair amount. Edit: I see people bringing up lazy file checkouts in conjunction with mounting a branch. For some of the enormous repos people work in this makes sense to me.

worktrees are cool, i find i need some bash aliases to like them as a human.

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

#188
post #50

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, conf…

I’ve been doing something similar with less dedicated workflow and generally works great

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

#189

    With AI, I can finally build what I've been dreaming about.
What was your dream before AI, exactly? Not to build a VCS for agents, presumably. But the entire value prop here is centered around agents.

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. 
So less context is an improvement? How much is 50% in practice? And how do my agents "need" a 90% speed increase (source, btw?) in VCS operations? What % of wall-clock time is spent in VCS commands vs actual inference?

"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
Who is "fighting worktrees"? If you're concerned about all these downloads, why not use worktrees over a network share, as mentioned in the git manual?
Post reply on HN