[flagged]
Show HN: Oak – Git alternative designed for agents
131–140 of 216 posts
Re: Show HN: Oak – Git alternative designed for agents
#132> but the speed is a consequence of the design, not the pitch.
You kinda lost me there. I‘m supposed to use a central technology whose author can’t be arsed to write a few paragraphs?
Re: Show HN: Oak – Git alternative designed for agents
#133From the github repo readme: > This repo was written almost entirely using AI with human oversight. If you see anything that needs fixed or would like to contribute, please email ... or reach out on Discord Why not just provide an email address that's delivered directly to the agents you have developing Oak? I didn't delve into the benchmark repo to understand what your loop is measuring. Why would an agent (without…
> Why would an agent (without fine tuning or oak-specific context) be faster with oak than it is with git or jj?
A large part comes from mounts. Being able to use FSKit/FUSE to make a change to a repo rather than doing a partial/full clone. A smaller part comes from having optimized context (json output) that agents are able to parse better with less tokens.
Re: Show HN: Oak – Git alternative designed for agents
#134I 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
What’s wrong with worktrees? To me that is exactly what mounting a branch would be. I use them a fair amount.
Edit: I see people bringing up lazy file checkouts in conjunction with mounting a branch. For some of the enormous repos people work in this makes sense to me.
Re: Show HN: Oak – Git alternative designed for agents
#135I 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…
> I really want to find reasons to like this But why? Why would I want to like a project which seems to invent problems rather than solve any? I don’t want to like this.
We don’t know if it’s inventing problems or solving them. That’s the point.
Re: Show HN: Oak – Git alternative designed for agents
#136Earlier quoted context omitted.
Hmm - of course I went looking for the past HN discussion and it seems there wasn't one - that's a bummer: Show HN: Open-source version control for game developers - https://news.ycombinator.com/item?id=36485377 - June 2023 (0 comments) (Hopefully we're making up for it with this one) Edit: ah here we go: Show HN: A version control system based on rsync - https://news.ycombinator.com/item?id=34439461 - Jan 2023 (118…
Actually this https://news.ycombinator.com/item?id=34439461 contains some great discussion about JamHub if people are curious. I changed the name from jamsync to jamhub. :) Partially why I got so excited about version control is how well this post blew up when I posted.
Oh good! Added above.
Re: Show HN: Oak – Git alternative designed for agents
#137Earlier quoted context omitted.
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.
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.
Re: Show HN: Oak – Git alternative designed for agents
#138I 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…
How much of that is due to the git CLI and how much of that is inherent flaws with the git VCS?
I know git (the VCS) can become a bottleneck with massive monorepos at the scale of Linux or Microsoft. But is anyone likely to port them to something new just to be a little more agent friendly? And if the goal of this new VCS was to make life easier for large monorepos (for humans as well as agents) then why doesn’t the author mention that on the project’s website? Because that’s exactly the kind of thing that might make this an easier sell to project teams.
Re: Show HN: Oak – Git alternative designed for agents
#139Anything "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 be a little less smooth sailing, but not by much.
Re: Show HN: Oak – Git alternative designed for agents
#140The 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.