8 ms·

Show HN: Oak – Git alternative designed for agents

• stealthy_ 4mo ago
  is it like re-gent.dev ? would love to understand the difference
• chadgpt3 4mo ago
  [flagged]
  • booleandilemma 4mo ago
    [dead]
  • ianm218 4mo ago
    > Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something. From hacker news guidelines https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
    • deleted 4mo ago
      [deleted]
• Pet_Ant 4mo ago
  What I want from a version system is to capture event in history not like changes as a files but as events that capture a process. If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes. I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file. Just a more human centric perspective on change history where it captures the way we talk and think about changes.
  • WolfeReader 4mo ago
    "I wish commits could be folded into larger commits so that you can still capture the individual changes but also not see them by default when looking at the history of a file." Fossil merges do this. More people need to use Fossil; it's got a ton of great ideas. "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." Now this is a good idea that I've never seen in a VCS.
    • packetlost 4mo ago
      > "If I split a file in two I still want to be able to see blame correctly for the author of the function, not one file as freshly created and the other with a bunch of deletes." > > Now this is a good idea that I've never seen in a VCS. There's a reason no one has done that, the VCS would have to have a semantic understanding of what it's tracking. I'm sure that's possible, but I think would see extremely limited success. Honestly, it may have even been done for proprietary languages and VCS systems that have since faded into obscurity. I'd settle for searching the git history for a particular regex/string and then running a blame on that.
      • tlb 4mo ago
        git actually does this. `git diff --find-copies`
• sourdecor 4mo ago
  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 https://i.sstatic.net/4vbd9.png
  • stouset 4mo ago
    Jujutsu might be what you’re looking for then.
    • LoganDark 4mo ago
      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 to think at all about the stuff I hate about git (babying the index, being careful to amend and etc. right the first time because undos are annoying, etc.) Does not support LFS or submodules though. [0]: https://github.com/LoganDark/get-shit-done/tree/jj-vcs https://github.com/LoganDark/get-shit-done/tree/jj-vcs
      • tcoff91 4mo ago
        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.
        • steveklabnik 4mo ago
          Submodules are already that way as well.
          • y1n0 4mo ago
• IshKebab 4mo ago
  Does this try to solve the biggest problems with Git: submodules and LFS?
  • zdgeier 4mo ago
    Planning on some monorepo features soon that should solve some submodule problems but haven't approached yet. I have some new ideas here. And yes, no separate LFS system!
    • IshKebab 4mo ago
      > 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?
      • zdgeier 4mo ago
        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.
        • philipwhiuk 4mo ago
          This sounds similar to Epic Games' Lore approach - have you seen what they're doing? https://epicgames.github.io/lore/explanation/system-design/ https://epicgames.github.io/lore/explanation/system-design/ if not
          • zdgeier 4mo ago
            Yes Lore looks awesome! I was previously working on a VCS for gamedevs -- that space definitely needs something better than Perforce haha. My comment would be that I think you need to nail a new GitHub + Git to really be successful in the space and I'm not sure Epic is focused on this. I wonder if Lore will turn out similar to Unity Version Control which is very specialized to Unity workflows or something more general. Definitely love what they're doing though.
• achandlerwhite 4mo ago
  Grammar nitpick: "anyways" should almost awlays be "anyway"
  • isodude 4mo ago
    "awlays" should almost always be "always"
  • applfanboysbgon 4mo ago
    https://www.merriam-webster.com/dictionary/anyways https://www.merriam-webster.com/dictionary/anyways
• sublinear 4mo ago
  Lots of self-promotion, but no concrete comparisons where this tool does a better job than git. The only thing to go on is this single sentence: "With virtual mounts, agents locally and in the cloud no longer need a full copy of a repo to get working." > For the first 100 users that subscribe to a paid plan I will send you a personalized e-ink display I don't understand anyone who feels incentivized by this. Brogrammer 2.0 is weird.
  • zdgeier 4mo ago
    Check out the homepage! https://oak.space https://oak.space might have what you're looking for. I can answer any questions you have here as well.
    • dang 4mo ago
      Since this project hasn't appeared on HN before and is obviously of interest to people, I've taken the liberty of turning your post into a Show HN (which is the convention for sharing your work on Hacker News - https://news.ycombinator.com/showhn.html https://news.ycombinator.com/showhn.html). I used the text from your blog post that explains what the project actually is - this is the bit we need to lead with, to stanch all the "I can't tell what this is" comments. I hope this is ok! If you prefer different text at the top, let us know at hn@ycombinator.com.
  • manwithopinions 4mo ago
    The blog post is a terrible intro, the website is much more insightful: https://oak.space/ https://oak.space/ I found the section titled “Local feature branches. Server main. One squash.” most interesting.
• weinzierl 4mo ago
  "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.
  • Banditoz 4mo ago
    What is git not suited for in modern development? I haven't found any reasons.
    • jayd16 4mo ago
      Git is great but if you really haven't found any reasons then you haven't looked at all. From large files to sub modules to hook permissions and file permissions... The list goes on and on about what where git falls short. There's plenty of workarounds too, but that's what they are. Workarounds.
      • gchamonlive 4mo ago
        Do you know if Jujutsu addresses these issues?
        • deleted 4mo ago
          [deleted]
        • hn92726819 4mo ago
          jj does not have large file or submodule support, but it does intend to in the future (you can read their design docs). Right now it's git compatible, so I'm not sure how 'permissions' would be stored compatibly, or what that means. I'm guessing ownership and xattrs
        • steveklabnik 4mo ago
          With the git backend, jj inherits git's problems. So right now, it does not, at least directly. With other backends, it inherits their problems. But also their solutions :) So with those backends, it could!
• noelwelsh 4mo ago
  A few comments: * The core idea sounds interesting. Make it the first paragraph, not paragraph seven. * Spend more words describing what makes Oak different. * "I built a version control system in my free-time called Jam". You probably didn't name your free time. "I built a version control system, called Jam, in my free time."
  • philipwhiuk 4mo ago
    "I built a version control system, in my free-time, called Jam" is fine.
    • stonogo 4mo ago
      It's also fine without the commas, because nobody was confused by that structure.
      • pepa65 4mo ago
        Without comma's it might require a re-parse.
    • AdamN 4mo ago
      Just "I built a version control system called Jam". The free-time thing is good for a history page but the homepage needs to tell the important part (you've got history and expertise in this subject) and then move onto what the vision is for Oak and what kind of help you need.
• ks2048 4mo ago
  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 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.
  • dang 4mo ago
    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 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 https://oak.space/blog.)
    • zdgeier 4mo ago
      Awesome, thanks! You could also change it to the homepage if you'd think that would work better for people. https://oak.space https://oak.space
      • dang 4mo ago
        Ah thanks - I forgot to change the top link. In this case I think https://oak.space/oak/oak https://oak.space/oak/oak is probably more enticing to the community because they get to see what it actually looks like - so I've used that URL instead.
        • zdgeier 4mo ago
          Sick, looks great!
• nixosbestos 4mo ago
  Yeah, I'll just wait for jj to get more virtualized FS features, and be very, very happy with that.
  • zdgeier 4mo ago
    I love jj! Martin is really awesome and love his work. I know they're using a VFS backing inside Google for their monorepo, wonder if we'll get some of those cool features on the outside.
    • steveklabnik 4mo ago
      There is a Google intern project to work on an open source vfs thing, we'll see how it goes.
• codymisc 4mo ago
  [flagged]
• vova_hn2 4mo ago
  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"?
  • zdgeier 4mo ago
    "download everything" means that you don't have to do a full or partial clone of the repo to make a change. You can imagine agents running in the cloud need to spin up and access the repo for every task, this can be slow for large repos (also small repos with large files). Also locally, worktrees can be a pain to manage with conflicts, confusing branching, and you can't check out the same branch multiple times. But I do agree that we're probably still pretty early on in the agentic adoption that many users using agents in git-like ways will not see much performance improvement.
  • ilc 4mo ago
    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.
• deleted 4mo ago
  [deleted]
• jazz9k 4mo ago
  It's kind of like replacing Wordpress. Sure, you can make a better alternative. But replacing an entrenched player that has been there for at least a decade will be almost impossible.
  • dgellow 4mo ago
    you don't need to replace, you just need to find your niche, then expand from there
• agalamli 4mo ago
  seems like an interesting idea. the only friction would be to get people to use it instead of git, however i believe it will happen slowly, more people trying it and recommending it to others.
  • zdgeier 4mo ago
    Totally agree. This is going to be the hardest dev tool to get people to switch, but we're trying! I think there's going to be many more players in this space in the next year or so. It'll be interesting to see what shakes out.
  • manquer 4mo ago
    There are git clients for perforce, hg, svn and so on[1]. Oak' developer (or the community) could always develop a git frontend for users who prefer that . [1] https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-a-Client https://git-scm.com/book/en/v2/Git-and-Other-Systems-Git-as-...
• kjuulh 4mo ago
  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 https://github.com/kjuulh/gitnow
  • zdgeier 4mo ago
    Looks awesome!
  • sipjca 4mo ago
    I’ve been doing something similar with less dedicated workflow and generally works great
• pixlmint 4mo ago
  Did you have your agent talk you into making this something separate over building on top of git?
  • zdgeier 4mo ago
    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.
    • zdgeier 4mo ago
      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 https://fossil-scm.org
      • andrewshadura 4mo ago
        D. R. Hipp, not Dr. Hipp.
        • cornstalks 4mo ago
          He earned a PhD…
          • andrewshadura 4mo ago
            Still not a doctor, as he himself confirmed.
            • cornstalks 4mo ago
              A PhD is a Doctor of Philosophy, so unless that PhD has been invalidated he is in fact a doctor. I don't know his personal preferences so perhaps he doesn't like to be referred to as a doctor (based solely on what you're saying). But there was nothing factually incorrect about the poster saying "Dr. Hipp."
• GroksBarnacles 4mo ago
  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."
  • gitpusher 4mo ago
    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)"
    • ianburrell 4mo ago
      The solution is to always add a second name. Like people, projects could have short name and full names. Could be organization (Apache Spark), could use type (Oak Versioncontrol), could be longer name (Violet Spring). Then can use short name internally, and full name globally. I like the type name cause tells what it is.
    • GroksBarnacles 4mo ago
      I'd suggest a descriptive name. Baking what makes it unique in the name would be ideal, but even narrowing it down to a category, like your version of my message had, would be an improvement. Knowing what class of thing the noun is would be an improvement over a tree or a or a sound effect or an obscure foreign concept being equally interchangeable as titles. Further, while your version wven presupposes that the name is useful enough to narrow it down to a category, if the name was specific enough it would avoid the confusion of your example. "Which program of this category? Oh, the one with that unique feature."
  • jayknight 4mo ago
    Aren't all product names "random" words before they become well known? Some are more descriptive than others, but they're all arbitrary to begin with.
• hnlmorg 4mo ago
  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
  • zbowling 4mo ago
    >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.
    • PunchyHamster 4mo ago
      checkout repo into tmpfs
    • grayhatter 4mo ago
      > Eh, it depends on the workflow. Especially if you have certain stack based workflows. I would normally assume there's 0 percent chance that `git` (the binary) is a significant impact on LLM based devel. The same applies to git, the protocol/format/tree. I'd love to hear about what makes the workflow you have, where any part of git becomes a noticable proportion of the process? Unless you mean your LLM just can't figure out how to use git?
    • hnlmorg 4mo ago
      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.
• robby1110 4mo ago
  Certainly an interesting project although I am wondering what makes the benefits mentioned agent specific? You have mentioned performance improvements which is great but in that case would it not just be a better vc than git in general? what perks only work with agents that wouldn't work with individuals?
  • zdgeier 4mo ago
    Thank you! The bet we're making is that agents will need to work on tasks much faster and with more parallelism than humans do with Git right now so these performance metrics will matter more. Git is awesome for human work so I'm not sure these metrics really matter than much to people. But also for agents, worktrees are not the best (can't work on the same branch in multiple places) and also the speed at which branches/PRs are created, need to be merged, etc. will need to be way faster and simpler since keeping up-to-date with how fast things are being modified is really important.
• CrzyLngPwd 4mo ago
  Back in the day, 2020, the effort to create a program/website/service was the prohibiting factor, which meant the sediment remained at the bottom of the barrel where it belonged. Now, every brain fart is published as a finished product no one wanted.
• pnw 4mo ago
  Zach is underselling his achievements here, having previously built the Jamhub VCS which was acquired by a well known founder.
  • dang 4mo ago
    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 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 https://news.ycombinator.com/item?id=34439461 - Jan 2023 (118 comments)
    • zdgeier 4mo ago
      Actually this https://news.ycombinator.com/item?id=34439461 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.
      • dang 4mo ago
        Oh good! Added above.
• coldstartops 4mo ago
  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 files, or large files with random jumps in them.
  • zdgeier 4mo ago
    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 https://oak.space/oak/benchmarks
    • coldstartops 4mo ago
      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 https://github.com/KeibiSoft/KeibiDrop
    • kccqzy 4mo ago
• mohsen1 4mo ago
  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
  • zdgeier 4mo ago
    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.
    • kccqzy 4mo ago
      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.
      • zdgeier 4mo ago
        I do think hosting is an important part of the VCS story. I agree that hg and jj and sapling are capable of being front ends to a google3 like backend GitHub like thing to support it (Google has this internally for jj). Of course some people are working on hosting solutions for these but it feels wrong to me that hosting platforms and their underlying VCS are not made by the same team. IMO people like google3 so much because it’s one integrated system which is the approach I’m trying with Oak.
        • kccqzy 4mo ago
          Well even at Google the hosting solutions and the VCS are not made by the same team. I lack imagination in thinking how being made by the same team can improve things, but that’s on me. Good luck!
• blurbleblurble 4mo ago
  For concurrency reasons Pijul is an excellent git replacement for agents in my experience.
• no_circuit 4mo ago
  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.
  • zdgeier 4mo ago
    Definitely agree and great points. This is going to be a very busy space in the next year. haha I've never used ClearCase but my friend told me about mounting VOBs in ClearCase so I'm excited it bring it back. Thanks for your thoughts!
• forty_one 4mo ago
  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!
  • zdgeier 4mo ago
    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!
• desmondl 4mo ago
  I would have loved to try locally, but the installer asks me to create an account and I don't want to do that yet.
  • zdgeier 4mo ago
    Agree we should definitely support offline flow. You can download the binary manually if you would like [1]. Although the offline/self-hosted flow isn't fully tested right now, would love some feedback on it if you're able to check it out! [1] https://github.com/oakdotspace/oak/releases https://github.com/oakdotspace/oak/releases
• SwellJoe 4mo ago
  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.
  • deleted 4mo ago
    [deleted]
  • mrmrs 4mo ago
    Totally correct on the burden of proof here. Agents DO know git extremely well. There’s a huge amount of git in model training data, and anything new starts behind because you have to teach the model what it is, what commands to run, and where the sharp edges are. For us “for agents” does not mean “new syntax that we hope agents can read docs for.” The thing we’re trying to optimize is not whether an agent can remember the command. It’s the runtime shape of agent-driven development. When an agent drives a VCS through a captured terminal, things that are tolerable for humans become direct costs: clone/setup time, worktree setup, full status output, huge diffs, branch cleanup, interactive prompts, shared-checkout mutation, repeated preflight checks. Those costs show up as wall time, bytes over the wire, transcript tokens, and recovery steps. So the Oak bet is narrower than “agents can’t use git.” They can. The bet is that if you assume branch-per-agent workflows, lots of parallel sandboxes, large repos, and non-interactive command execution, the VCS interface should have different defaults if you want to optimize for shipping speed and efficiency of token usage. If you're already going fast enough and not running out of tokens - then using oak seems pretty silly. People do not need to ditch git to try Oak out. One workflow we care about is letting agents work in Oak where the agent-specific costs matter, then exporting back to git for the human review, CI, release, or compliance workflows. Totally agree this should be provable and benchmarked. The homepage has Oak vs Git numbers because we do not want “for agents” to just be vibes. We’re measuring transcript bytes, estimated tokens, tool calls, wall time, large diff/status behavior, and contention in agent-style workflows. We’re also working on the benchmarks repo in the open: https://oak.space/oak/benchmarks https://oak.space/oak/benchmarks The exciting part to me is that we can already improve on tokens and timing despite starting with the model-prior deficit you’re describing. If we can win on measured agent workflows while git still has the advantage of being deeply baked into the models, I’m incredibly bullish on where Oak can get to as the tool and the ecosystem matures. Longer term, if Oak proves useful and sticks around, future frontier models will likely have more Oak examples in training data, which lowers the upfront learning tax for an extra boost.
• teaearlgraycold 4mo ago
  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.
  • mrmrs 4mo ago
    Not sure about the accuracy of the first sentence but agree we have a lot of work to do on the UI and narrative front! Most of my focus as a designer has been on the CLI itself. I use oak to develop oak and want the experience for agents and humans to be as smooth and wonderful as possible. The landing page is not up to our own standards yet but we are iterating every day to try and improve it. Hope to make the content more approachable for you and others soon. Really appreciate the feedback.
• croes 4mo ago
  Given 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
• whalesalad 4mo ago
  Could 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.
  • zdgeier 4mo ago
    Could probably build a Git backend at some point for people to use kind of like how jj does it. Right now my goal with this is to see what's possible natively if we don't try to build on top of Git. But definitely agree that the wording needs to be improved here to explain what benefits we get from not building on git (better mounts, built-in LFS, clearer branching/workflows, etc.).
• vcryan 4mo ago
  I think git it the perfect system to bring order AI coding. Generate code however you like, but ultimately, it goes through a sensible, proven, and auditable pipeline. As someone also building AI tools, git it something I find myself "building with" - not against.
• hanneshdc 4mo ago
  I actually like this. I thought I wouldn’t because it’s just another git - but git worktrees are a PITA. Can I suggest though to focus the readme on the lighting fast checkout for multi agent loads? That seems to be the big selling point and is the real win over git. I think other commenters here are missing the point - it’s not “for agents” in that the API is somehow agent friendly. Of course git being omnipresent in the training data gives it a one-up. It’s “for agents” in that it aligns with a multi-checkout workflow better than git does.
  • zdgeier 4mo ago
    Great point, the readme for this repo is not great right now and we have a bunch to improve on that people have pointed out. Thanks!
• Nicolau_Amorim 4mo ago
  [flagged]
• russellthehippo 4mo ago
  "Welcome to the agentic substrate" YAAS (yet another agentic substrate)
• harshreality 4mo ago
  From 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 fine tuning or oak-specific context) be faster with oak than it is with git or jj?
  • fellowmartian 4mo ago
    “Why not just provide an email address that's delivered directly to the agents you have developing Oak?” Genuinely can’t tell if you’re joking or not.
  • zdgeier 4mo ago
    > 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.
• sarracin0 4mo ago
  [flagged]
• zane_shu 4mo ago
  [flagged]
• manmal 4mo ago
  > 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?
• uproarchat 4mo ago
  Wow that interface tingles something inside my brain.
  • zdgeier 4mo ago
    A good tingle or bad tingle? haha
    • uproarchat 4mo ago
      real good
• bwhiting2356 4mo ago
  > 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?
  • zdgeier 4mo ago
    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.
• danpalmer 4mo ago
  The focus on speed is interesting here, it's something I think less and less about with agents. I'm not waiting for git operations, and at the rate agents run it's just not a major factor. Agentic development is all about throughput, not latency. This looks interesting regardless, but I do wonder if the latency focus is the wrong way to sell this.
  • zdgeier 4mo ago
    True, I do wonder if we focused more on the parallelism aspect with mounts that it would resonate with people more. Thanks for the thoughts!
• N_Lens 4mo ago
  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.
  • zdgeier 4mo ago
    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?
    • adastra22 4mo ago
      That’s like asking if a relationship can improve to a point that communication is no longer necessary. It misses the point.
• jing09928 4mo ago
  [flagged]
• CHUNK_CHUNK 4mo ago
  Interesting to see more dev tools designed specifically for agent workflows. I've been building a local tool that monitors AI agent API calls and costs in real time — the "I have no idea what my agent just did" problem feels like it's only going to get bigger as agentic coding tools spread.
• drob518 4mo ago
  Oh, it’s “for agents,” you say. Well, I’m sure that makes all the difference.
  • zdgeier 4mo ago
    It's also made for humans as well :) We have some nice TUI stuff in the CLI that you might like. Check it out if you're curious and let me know if you have any thoughts.
• andunie 4mo ago
  Wait, I clicked and read, but I still don't know what is this about!
  • zdgeier 4mo ago
    Happy to describe or answer questions here. It's a version control system (like Git/GitHub) designed for agents. Some specific things that make it different than git are a simplified branching system and networked mounts so you can work on tasks on a repo in parallel.
    • andunie 4mo ago
      Sounds good, but isn't that too little to justify moving out of git? Why couldn't this be written on top of git?
• insane_dreamer 4mo ago
  anything that improves on git's branches vs worktrees mess is a GoodThing, imo
• isabellehue 4mo ago
  [flagged]
• AhmedRafat534 4mo ago
  [flagged]
• jatins 4mo ago
  [dead]
• rahadbhuiya 4mo ago
  [dead]
• _pdp_ 4mo ago
  [dead]
• huflungdung 4mo ago
  [dead]
• GardenLetter27 4mo ago
  How is downloading stuff remotely the bottleneck here?
  • zdgeier 4mo ago
    Agents in the cloud (and locally) need to have a full repo, even if they only need a small percentage of a repo to make a change. You can also imagine if changes are being made in the cloud by multiple agents, each one of these agents need a shallow clone at the very least. If you're spinning up many agents in the cloud this becomes a bottleneck. So not really that downloading things is a bottleneck, it's that agents need to download way less to make the same decisions and changes.
• Beigale 4mo ago
  [flagged]
• sugihaf 4mo ago
  [flagged]
• mpalmer 4mo ago
  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?
• madikz 4mo ago
  [flagged]
• Ainaguade 4mo ago
  [flagged]
• deleted 4mo ago
  [deleted]
• james-mxtech 4mo ago
  [dead]