Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News

  •     With AI, I can finally build what I've been dreaming about.
    What was your dream before AI, exactly? Not to build a VCS for agents, presumably. But the entire value prop here is centered around agents.

    This is not the first "agentic VCS" project which claims both N% VCS token savings, and "faster VCS operations". But how are either of these two things a bottleneck? No case is made for this.

        It dramatically improves the speed and context your agents need when working on serious projects: 50% fewer VCS-related tokens and 90% faster per operation.
    So less context is an improvement? How much is 50% in practice? And how do my agents "need" a 90% speed increase (source, btw?) in VCS operations? What % of wall-clock time is spent in VCS commands vs actual inference?

    "Agents locally and in the cloud no longer need a full copy of a repo to get working" - but was that ever a problem? And git supports shallow clones anyway.

        work on many tasks in parallel without needing to download everything or fight worktrees
    Who is "fighting worktrees"? If you're concerned about all these downloads, why not use worktrees over a network share, as mentioned in the git manual?
    by mpalmer
  • > 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?

    by manmal
  • I have always wanted a version control system that was basically Emacs/Vim/Neovim's undo-tree[0] but persistent and social. Why do I have to manually talk to git? You are a computer, track every modification I make while editing and let me decide (or help me decide) on what a checkpoint is.

    [0]: https://i.sstatic.net/4vbd9.png

    by sourdecor
  • Zed’s DeltaDB is that very idea I believe

    https://zed.dev/deltadb

    by iknowstuff
  • Jujutsu might be what you’re looking for then.
    by stouset
  • I would recommend just linking to a few sentences that say how Oak is different than Git, rather than a personal backstory. (https://oak.space/docs)

    My initial reaction is if this is not something than could be built on top of Git, rather than replacing it. Describe the data model - what is a "commit", what is a "branch" ..., if the same as git, then why not reuse.

    by ks2048
  • Since many commenters had a variant of this response, I've turned the post into a Show HN above (more at https://news.ycombinator.com/item?id=48633408).

    (The submitted title was "Git is forever. I'm building Oak anyways." and the submitted URL was https://oak.space/blog.)

    by dang
  • This project falls into the classic "More" trap. Agents are fast at creating code so let's make them even faster (more). However any rational observer can see that the bottlenecks for throughput are no longer at this segment of the process.

    Human decision-making, communications and awareness are the key bottlenecks, not code generation and commit speed, by several orders of magnitude.

    And I think that's a good thing if we want to avoid mass-psychosis.

    by N_Lens
  • Do you think it's possible in the next few years or so that agents will improve to the point that some of approval work can be offloaded to them?
    by zdgeier
  • Did you have your agent talk you into making this something separate over building on top of git?
    by pixlmint
  • 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.
    by zdgeier
  • Looks very interesting, but it's difficult to see the benefit from git right now apart from performance? Don't get me wrong, that's good, but I don't think it's a big enough proposition to get people to ditch git and move to oak.

    Since it's early, here a couple of things I'd loooove git to be and it's not, maybe you can consider to go in this direction and, if there are many more like me, get a large user base: - The private/public quantum shouldn't be a repo but something more fluid within a repo. A public repo should be able to have private sub-directories, files, etc. If should be fluid in this regard, so big projects could open-source <i>some</i> features, not all. Right now it's all or nothing, and that closes the doors to many big closed projects. - env variables. If you could make its usage easier and more seamless within oak, that could convince many (me included). It's really a headache to deal with env vars and git, and shouldn't be the case. - Collaboration for agents beyond PRs. I don't know exactly what's the flavor for this, but I know that fundamentally the create PR/merge circle of git is not how it should be.

    Great initiative and good luck!

    by forty_one
  • Totally agree with everything. Definitely will be hard to get people to switch. Also love the monorepo idea you mentioned. It should totally be possible to keep the benefits of a monorepo without the downsides of git submodules. So you should be able to open-source parts of a repo without open sourcing the whole thing. One of the benefits of building from scratch is that this is pretty straightforward. Also the other ideas you mentioned are really awesome. Thanks!
    by zdgeier
  • Zach is underselling his achievements here, having previously built the Jamhub VCS which was acquired by a well known founder.
    by pnw
  • 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 comments)

    by dang
  • 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

    by mohsen1
  • 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.
    by zdgeier
  • 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 incompatibilities with all the established git ecosystems?

    I really want to find reasons to like this but it’s probably some of the worst product marketing I’ve seen. And something this significant really does need to sell itself hard if you’re going to get enough people in a project team to agree to switch away from git

    by hnlmorg
  • >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 in a boneheaded way. Now I have AGENTS.md/skills/hooks gaurdrails littered about to try and work around things.

    by zbowling
  • > 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.

    by laserbeam
  • 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
    by desmondl
  • I've built my own workflow for using agents on git, as i now often have to do changes across repositories, or in the same repository for different tasks. I could use worktrees, but I'd rather invert it, give agents the ability to have a workspace, that they pull repositories into, create branches as they want, commit on main it doesn't matter. the agents don't bother each other, and when i finally have to merge, conflicts are either resolved, or it is just smooth sailing.

    The tool is called gitnow. it is honestly quite simple, just create a project, add the repositories you want and get to building. I've found having another claude chat or whatever use the tool to great success coupled with zellij, but could also be zed, tmux or whatever.

    Secondly it also pretty much solves the problem of the agent dumping memory files everywhere, they now basically have a scratch space that is theirs, where they can keep their tasks, and just update the repositories as needed.

    Use gn the shell after eval if you use it, it will actually invoke cd, instead of creating a subshell.

    https://github.com/kjuulh/gitnow

    by kjuulh
  • Looks awesome!
    by zdgeier
  • I’ve been doing something similar with less dedicated workflow and generally works great
    by sipjca
  • 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 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. Models can, of course, follow documentation, so there's nothing stopping them from using the new thing...but, the new thing "for agents" starts the race well behind the known thing that was built for humans a decade or two ago and has huge amounts of training data baked into every model.

    I'm not saying nobody should make new things (an accusation I've gotten when saying something similar about a previous "for agents" thing), of course people should make new things. I'm saying that when I see "for agents", I think, "prove it". Agents don't have trouble with git, so there's gotta be some kind of pain point about using git with agents that I'm unaware of that this solves somehow (but isn't expressed on the page) or this isn't actually for agents, it's just a project someone wanted to do (and that's also fine!). But, if the latter, "for agents" is merely marketing and I'm not interested.

    by SwellJoe
  • I cant agree more.
    by hansarnold
  • 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".
    by codesnik
  • * It dramatically improves the speed and context your agents need when working on serious projects: 50% fewer VCS-related tokens and 90% faster per operation.

    Sounds like a good optimization to me. VCS is a waste of tokens for sure. I’m intrigued to hear more.

    by bottlero_cket
  • Totally agree. I used to work with a team that built a project for creating ontologies of Git repositories. The goal was to help LLMs onboard faster and navigate the repo better.

    In the end, it became heavy overengineering: people no longer understood not only the repo itself, but also the extra layer describing it. Meanwhile, coding assistants are already quite good at reading codebases directly.

    by PashaGo
  • Git has worktrees, which provide a means of creating branch linked physical working directories. I built in UI assistance for creating worktress associated with the agent session in https://www.agentkanban.io (an agent integrated kanban board for use with copilot / claude and vs code). I agree, I would rather try and make use of a tool that the agent is already familiar with, unless it's missing features that the agent needs to achieve its goal (which git is not)
    by gb2d_hn