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.
Show HN: Oak – Git alternative designed for agents
101–110 of 216 posts
Re: Show HN: Oak – Git alternative designed for agents
#102Given the promise of AI it doesn’t need special treatment to handle our data we change a lot to please the needs of AI.
Like replacing streets with rails while we claim FSD works out of the box
Re: Show HN: Oak – Git alternative designed for agents
#103I 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 main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it
I've heard of this before but never tried it: https://wiki.archlinux.org/title/Gitfs
Re: Show HN: Oak – Git alternative designed for agents
#104Could 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.
Re: Show HN: Oak – Git alternative designed for agents
#105I 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 main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it
> messageless commits for intermediate work
Would this be like `git commit --allow-empty-message`?
Re: Show HN: Oak – Git alternative designed for agents
#106I 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…
Couldn't run your benchmarks, as I did not create an account, and a bit of a different beast that I am comparing against (P2P distributed filesystem), but these are my numbers and setup, and the on-demand part lines up with what I have observed:
Setup: a Linux box on the other side of Romania (compared to where I am living) reading from a Windows box in Singapore (~200 ms RTT)
- reading 1 MiB of a 1 GB remote file pulls only 16 MiB (~98% avoided) - this is because of my fine tuning optimization choice - first byte approx: 2.3s - git-LFS repos also clone cold over the mount byte-perfect (separate Mac - Linux run on a ~20 ms RTT)
The thing that I do differently is that my metadata is eagerly pushed, as I optimized for content streaming.
And 100k-file tree mounts I did not test yet.
But my goal was to have instant file access for generic files between apps, and peer to peer, supports also Windows :D
here is the tool: https://github.com/KeibiSoft/KeibiDrop
Re: Show HN: Oak – Git alternative designed for agents
#107Re: Show HN: Oak – Git alternative designed for agents
#108Earlier quoted context omitted.
Game development, with very large assets. Also, git is pretty terrible with non-text files.
You're diffing very large assets?
Is that surprising? It’s pretty common in anything game dev related, that’s why perforce is still in use, despite its horrible UX
Re: Show HN: Oak – Git alternative designed for agents
#109Anything "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…
[deleted]
Re: Show HN: Oak – Git alternative designed for agents
#110Earlier 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 already that way as well.