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

141–150 of 216 posts

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

#141

Post by skissane »

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…

> Models know git because there's a monstrous amount of git in their training data. Models never heard of a new thing "for agents", so you have to teach them to use it via skills and docs.

Another option: when model invokes standard tool, rewrite the invocation to newfangled tool.

Bunch of ways of doing it:

(a) Invocation of standard tool returns error saying to use newfangled tool instead

(b) Invocation of standard tool returns message saying it has been dynamically rewritten to invoke newfangled tool, followed by newfangled tool output

(c) Invocation of standard tool in context is dynamically rewritten to invocation of newfangled tool, prior to execution

In case (c), the model ends up thinking it somehow knew about this new thing all along, even though it actually didn’t

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

#142

Post by ilc »

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

I could, I hit it in some situations. But I'm running some fair size repos where I do multi-worktree work.

That said, it hasn't been enough of an issue for me to want to fix.

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

#143

Post by kccqzy »

zdgeier wrote: post #140
mohsen1 wrote: post #82

The lazy mount is very interesting. This is similar to how google3 works at Google that I have not seen any similar implementation in open source so far. Git sparse checkout is helpful but checking files out as they are needed is much more flexible and intuitive. Microsoft VFS for Git / GVFS is the closest that I can think of. There is room for this lazy mount idea to be built on top of Git

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.

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

#144

Post by kccqzy »

zdgeier wrote: post #81
coldstartops wrote: post #78

I am curious, how do you handle latency issues for on demand access? I saw you use FUSE (and FSKit), and from my experience it is pain to make filesystems in userspace work on-demand over WAN because a) latency, and variable RTT; and b) you can't saturate the wire and aggressively read ahead things, otherwise native apps will freeze, lag, or just make the UX unpleasant, especially if there are too many placeholder fi…

I think what makes FUSE/FSKit great here is that agents usually only need to see the file metadata + read a handful of actual files, rather than some applications needing read many things. If you're doing huge rewrites, this is a problem, but most tasks are usually somewhat small. Definitely is a problem that I've ran into though, we do cache aggressively to try to solve some of this, but it'll never be as fast as re…

That unfortunately doesn’t match my experience at all. My Claude often runs rg in the repo attempting to find things that need to be changed. And of course Claude still needs to invoke the build tool to ensure the change can be compiled, which necessarily involves reading almost every single file at least for a fresh checkout? Or did you envision the build tool being completely remote?

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

#145

Post by sdesol »

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 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 agent use oak all the time is not an issue in my opinion.

The challenge for oak is why? Considering how I actually want to slow agents down so I can ensure it is doing the right thing and because the massive bottle kneck is the LLM themselves, speed when measured in milliseconds or even seconds will not concern many.

I thought oak was more of, we know how to prompt inject context based on code that is stored in oak for example, but faster operations can help, but the use case is limited. The missing piece for better/correct code is context at the right time.

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

#146

Post by steveklabnik »

y1n0 wrote: post #137
steveklabnik wrote: post #110

Earlier quoted context omitted.

Submodules are already that way as well.

Mostly true, but the weird edge case I run into is workspaces. Since they seem to be independent of and not backward compatible with git worktrees, there is no fall back to git for submodules within a workspace. We still use submodules in a number of places at work so it’s a bit of friction for me. Other than that, I’m rapidly becoming a jj convert.

Ahh, so workspaces don't currently support colocation, aka "put a .git directory in there". So that's what's up there. Interesting corner case! I know upstream is working on it.

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

#147

Post by LoganDark »

tcoff91 wrote: post #63
LoganDark wrote: post #22

Earlier quoted context omitted.

Seconding Jujutsu! I've been working to add Jujutsu support to basically every open-source tool and framework I use, including the agentic ones [0]. While it doesn't work for everyone, I've found it can really work for some people. (like myself) It's absolutely great for keeping a bunch of exploratory changes alive, quick prototyping, etc. as I tend to do with basically every source I have on my machine. I don't have…

submodules are cursed. LFS support looks to be coming soon in the form of jj ignoring LFS files and just allowing you to use git-lfs to manage them.

Submodules are cursed, but I like to clone my repos without colocation, but then sometimes find that I need to re-colocate in order to `git submodule update`.

Relatedly, when I use filesystem paths as remotes they need to be colocated or else it doesn't work, which is a little annoying!

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

#150

Post by zdgeier »

bwhiting2356 wrote: post #149

> without needing to download everything how does your agent run tests or click around the UI to verify changes if it doesn't have the full code?

Good question, the files are grabbed on demand from the server so the agent can fetch everything it needs to run tests, a dev server, or anything it does normally. Now this might be slightly slower in some cases where the history is short, but the bigger the repo and files the more this makes sense. So the full code is available and buildable, just over the network instead of locally.

Another thing, inside these mounts build artifacts and directories like node_modules can act kinda weird, so we just have some extra context in the AGENTS.md to host these in a different location from the mount. or agents usually figure this out on their own in my experience.

Post reply on HN