Show HN: Oak – Git alternative designed for agents
181–190 of 216 posts
Re: Show HN: Oak – Git alternative designed for agents
#182Re: Show HN: Oak – Git alternative designed for agents
#183Re: Show HN: Oak – Git alternative designed for agents
#184Re: Show HN: Oak – Git alternative designed for agents
#185Re: Show HN: Oak – Git alternative designed for agents
#186Wait, 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.
Re: Show HN: Oak – Git alternative designed for agents
#187Earlier 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.
Re: Show HN: Oak – Git alternative designed for agents
#188I'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…
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?