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

161–170 of 216 posts

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

#161

Post by fulafel »

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…

How did you speed up things (eg clone, worktree setup) compared to Git? Could the same work for human facing tools?

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

#162

Post by nextaccountic »

sdesol wrote: post #145
atombender wrote: post #139

Earlier quoted context omitted.

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 think the issues is, it is going against a very well established pattern. I have a tool that wraps ripgrep so that search results always includes context and from time to time, the agent will use ripgrep by itself and when I ask why, it would go "yeah I should have done that" There are work arounds though and I am creating what I call knowledge triggers for Pi that are similar to claude's "PreToolUse" so having the…

> I think the issues is, it is going against a very well established pattern. I have a tool that wraps ripgrep so that search results always includes context and from time to time, the agent will use ripgrep by itself and when I ask why, it would go "yeah I should have done that"

There's a limit of how many simultaneous instructions an agent can follow (the exact number depends on the specific model so instructions that are fine for one model may overwhelm another). If this keeps happening, consider trimming your instructions or even better, solving it at the harness level (like intercepting and rewriting ripgrep calls to use your thing, like rtk [0] does in agents that supports this)

Overall, never leave to an agent an instruction that must be followed at all times. For example, doing things in a git hook beats a multi-command workflow every time the agent commit, etc.

Is this state of things forever? I don't think so. Very soon models will become so better this will be a non-problem

[0] https://github.com/rtk-ai/rtk

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

#164

Post by zdgeier »

andunie wrote: post #163

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.

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

#165

Post by pylotlight »

zdgeier wrote: post #70
pixlmint wrote: post #62

Did you have your agent talk you into making this something separate over building on top of git?

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 think everyones been asking for "what's next" around git for a while as well :P Theo certainly mentions it plenty.

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

#166

Post by zdgeier »

fulafel wrote: post #161
mrmrs wrote: post #112

Earlier quoted context omitted.

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…

How did you speed up things (eg clone, worktree setup) compared to Git? Could the same work for human facing tools?

Mostly through networked file system mounts with FSKit/FUSE backing when working on tasks in parallel. May be applicable for human facing tools but I think workflows there are already pretty set with having files locally and mounts need some lifecycles that agents are probably better at handling.

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

#168

Post by WolfeReader »

tlb wrote: post #54
Pet_Ant wrote: post #40

Earlier quoted context omitted.

If I run blame on the new file the will I see the commits made by the original writers? Will it find the same code if it was written independently? It’s not about find copies it about recording changes to a code base as an artifact and not to files. The closest git has is limited rename support.

Yes, if you run `git blame -C`.

I legit did not know this. Thanks!

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

#169

Post by codesnik »

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…

yep. claude keeps "habitually" trying to use `rg -rn` instead of `rg -n` because it was instructed to use "rg" instead of "grep" by Anthropic, but uses arguments for grep: `grep -rn`. My instructions and "memory" are not helping. "Oh, I did it again, and you've instructed me not to". Older tools are better for current "agents".

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

#170

Post by pepa65 »

stonogo wrote: post #30
philipwhiuk wrote: post #20

Earlier quoted context omitted.

"I built a version control system, in my free-time, called Jam" is fine.

It's also fine without the commas, because nobody was confused by that structure.

Without comma's it might require a re-parse.
Post reply on HN