Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Oak – Git alternative designed for agents

oak.space

Post reply on HN
Print view View original

121–130 of 216 posts

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

#121

Post by zdgeier »

dang wrote: post #117
pnw wrote: 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…

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.

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

#122

Post by mrmrs »

teaearlgraycold wrote: post #101

You're jerking yourself off with the web UI here. What I see on first load is essentially completely homogeneous, just a sea of black boxes with white text. As a purely aesthetic composition it's interesting to look at from afar. But in the context of presenting it to strangers it's hard to approach. Too much going on and hard to parse.

Not sure about the accuracy of the first sentence but agree we have a lot of work to do on the UI and narrative front! Most of my focus as a designer has been on the CLI itself. I use oak to develop oak and want the experience for agents and humans to be as smooth and wonderful as possible. The landing page is not up to our own standards yet but we are iterating every day to try and improve it. Hope to make the content more approachable for you and others soon. Really appreciate the feedback.

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

#124

Post by zdgeier »

hanneshdc wrote: post #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 i…

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!

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

#125

Post by harshreality »

From the github repo readme:

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

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

#126

Post by fellowmartian »

harshreality wrote: post #125

From the github repo readme: > 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…

“Why not just provide an email address that's delivered directly to the agents you have developing Oak?” Genuinely can’t tell if you’re joking or not.

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

#127

Post by oliver236 »

mrmrs wrote: post #112
SwellJoe wrote: post #100

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

[dead]

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

#129

Post by zdgeier »

whalesalad wrote: post #104

Could this not have been a git wrapper? I struggle to see why git had to be abandoned entirely. Now you need to rebuild the world just to add some ergonomics on top of git.

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.).

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

#130

Post by zdgeier »

vova_hn2 wrote: post #32

I cannot imagine git being a performance bottleneck in agentic workflow. > 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"?

"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.
Post reply on HN