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

81–90 of 216 posts

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

#81

Post by zdgeier »

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 reading/writing directly to disk. We have benchmarks [1] if you want to take a look at how we're testing some of the performance there.

[1] https://oak.space/oak/benchmarks

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

#82

Post by mohsen1 »

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

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

#84

Post by gitpusher »

GroksBarnacles wrote: post #66

I wish we as a society would stop using random words for products. "Slacked about Oak, but they need in Fizzle. The deck's in Slate, the assets are in Vault, the timeline's in Pulse, the copy's in Quill, the build's in Forge, and the launch party's already in Ember."

What alternative would you suggest? "Sent a message in our enterprise chat application about the version control system that our engineering team sometimes uses (no, not that one, the other one) but they need it in the project management app that our Design team uses (good luck requesting access from IT, we have more than a dozen project management tools in our catalog)"

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

#85

Post by PunchyHamster »

zbowling wrote: post #72
hnlmorg wrote: post #68

I have absolutely no idea what this offers that makes it better than git (or any over VCS for that matter) for agents. There’s some mention about performance, which is great, but the performance of git isn’t a bottleneck for agents. There’s some mention about token use being reduced, which is great, but how have they achieved that vs gits porcelain modes. And why does token count require a whole new VCS, and thus inc…

>the performance of git isn’t a bottleneck for agents. Eh, it depends on the workflow. Especially if you have certain stack based workflows. Worktrees are kinda half solution here but depending on the repo type and if you are dealing with LFS or sparse checkouts, I've had agents struggle really hard to work through a stack or rebase things without a lot of thrashing or being IO bound by just stumbling into operations…

checkout repo into tmpfs

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

#86

Post by PunchyHamster »

weinzierl wrote: post #9

"Git is forever" Many things were forever until they suddenly died, but I think this is especially true for git. I'm not saying this as a git hater, quite to the contrary. I think git is great. I also think git is an ill-fit for the majority of modern commercial software projects and there will be a breaking point where companies realize that and move on.

"Majority" is massive stretch. There are 2 main pain points:

* monorepo megarepos - but you kinda need system built from scratch that sacrifices a lot in other places to handle that in the first place * media asset heavy repositories - again, different paradigm. Stuff that make Git great like full local history just become impossible to do sensibly when amount of changes per day is hundreds of megabytes.

Most projects don't git that. And for majority git + LFS is enough.

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

#87

Post by IshKebab »

zdgeier wrote: post #19
IshKebab wrote: post #12

Earlier quoted context omitted.

> And yes, no separate LFS system! Awesome. How does one decide which files should be stored externally, and manage that? And where is that decision stored?

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 ways, but at least:

1. It conflates the content with the storage mechanism. You can't change retrospectively how the files are stored, even though the only thing you really need to be immutable is their content.

2. It requires you to actively set up git-lfs, otherwise it silently does the wrong thing.

3. Not exactly LFS's fault but I have yet to find a forge (GitHub, Gitlab etc.) which exposes the LFS stored files in a sane way. Last time I tried it was basically impossible to delete old files, and you needed a lot of extra work to even enable LFS in the place.

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

#88

Post by andrewshadura »

zdgeier wrote: post #71
zdgeier wrote: post #70

Earlier quoted context omitted.

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'm also secretly a massive fan of Dr. Hipp and his work on FossilSCM [1]. I love a bunch of his design decisions there and wanted to apply them to a new system. [1] https://fossil-scm.org

D. R. Hipp, not Dr. Hipp.

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

#89

Post by no_circuit »

My impression with this space is that you'd need to fundraise startup-style, which I'm assuming you'll do, to catch up with everyone that is doing a similar thing.

The problem space and solution has been around for a while in big tech, and now there is a handful known products publicly known, and probably a couple dozen still secret ones. It is just now with AI/agents volume, there probably needs to be an easier solution for quick narrowly focused VCS views.

For filesystem mount, usually FUSE-FS, of a version control system to enable multiple viewers without transferring a lot of data see some current/previous implementations:

- Google: Piper via CitC (Clients in the Cloud) often used with Cider (web IDE)

- Meta: Sapling on EdenFS (from what I read, never worked there)

- Rational Clearcase, anyone else remember mounting VOBs?

The main issue I see is with the site -- it just seems like a big blob of AI-generated text I need to understand what is going on. The cool part wasn't even shown off: your GitHub UI clone that you can get to from seeing the benchmark code.

FYI, I also think the 4-way arrows logo has been used before, and still might be in use. I tried searching, but I think I saw a multi-colored one, maybe in a UK-based IT corporate training company's class I attended.

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

#90

Post by FergusArgyll »

Imustaskforhelp wrote: post #57
iknowstuff wrote: post #45

Earlier quoted context omitted.

Zed’s DeltaDB is that very idea I believe https://zed.dev/deltadb

is there some more information about DeltaDB? this seems to be an early access feature and not something available at the moment but I would be interested to learn more about it. Edit: this was actually announced at a very recent blog post (11 july 2026 so just 11 days ago): https://zed.dev/blog/introducing-deltadb The blogpost also has some more relevant information as well.

Software is made between commits https://news.ycombinator.com/item?id=48492533 (214 comments)
Post reply on HN