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

171–180 of 216 posts

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

#171

Post by dbt00 »

atombender wrote: post #139
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…

I'm not sure I understand this argument. I create new tools all the time as part of my development work, and I have skills stored that tell agents how to use them. They use them flawlessly. When I say "benchmark the query engine using the foobar dataset and compare it to run 431", the agents go and run my special benchmark tool and use the different subcommands to compare results and so on. I'm sure a new VCS would b…

I use a new VCS already (jj, highly recommended) and Claude forgets to use it all the time despite many obvious instructions in many places.

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

#174

Post by gb2d_hn »

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…

Git has worktrees, which provide a means of creating branch linked physical working directories. I built in UI assistance for creating worktress associated with the agent session in https://www.agentkanban.io (an agent integrated kanban board for use with copilot / claude and vs code). I agree, I would rather try and make use of a tool that the agent is already familiar with, unless it's missing features that the agent needs to achieve its goal (which git is not)

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

#175

Post by hansarnold »

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…

I cant agree more.

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

#176

Post by mrmrs »

gb2d_hn wrote: post #174
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…

Git has worktrees, which provide a means of creating branch linked physical working directories. I built in UI assistance for creating worktress associated with the agent session in https://www.agentkanban.io (an agent integrated kanban board for use with copilot / claude and vs code). I agree, I would rather try and make use of a tool that the agent is already familiar with, unless it's missing features that the age…

Yes but each of these require an entire materialization of all files and assets which for some repos can be a non-trivial amount of waiting time and disk space when you are doing lots of things in parallel. You can also use worktree workflow in oak by cloning into separate spaces. This is sometimes ideal for even our own workflows depending on context, I personally do it often. Mount can be super advantageous in a lot of contexts and if you work at a certain scale, those margins of time savings matter. If you aren't hitting limitations with git - that is great for you and your workflow! Our general philosophy is that no one should feel limited by computers. We have been limited by git in certain contexts and are trying to solve our own problems and we have opened it up in the case it might be useful for others who have run into similar problems.

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

#177

Post by adastra22 »

kccqzy wrote: post #143
zdgeier wrote: post #140

Earlier quoted context omitted.

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.

If the goal is just to make it work like google3, then hg and jj and sapling can all already achieve this. There’s no need for a new contender here. The differentiation must come from something else. But of course at Google the file system part (CitC) is a layer beneath the version control system and is shared across different vcs tools.

Public hg and jj are just a front-end to git. No virtual file system overlay or anything like that. Meta has open sourced many of the components of sapling, but there is no plumbing to put it all together in the same configuration.

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

#179

Post by adastra22 »

IshKebab wrote: post #87
zdgeier wrote: post #19

Earlier quoted context omitted.

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.

So the problem that LFS solves is that sometimes you have large files that you a) don't want to download by default, e.g. old binary executables, b) are big enough that you want to serve them from a more efficient source e.g. S3, or c) are large and not needed forever, so you want to be able to delete them one day. LFS "solves" those but it does it really badly . Really really badly. I've probably forgotten all the w…

This thing is a centralized server version control materialized on demand.
Post reply on HN