Yes but each of these require an entire materialization of all files and assets which for some repos can be a non-trivial amount of waiting time and disk space when you are doing lots of things in parallel. You can also use worktree workflow in oak by cloning into separate spaces. This is sometimes ideal for even our own workflows depending on context, I personally do it often. Mount can be super advantageous in a lot of contexts and if you work at a certain scale, those margins of time savings matter. If you aren't hitting limitations with git - that is great for you and your workflow! Our general philosophy is that no one should feel limited by computers. We have been limited by git in certain contexts and are trying to solve our own problems and we have opened it up in the case it might be useful for others who have run into similar problems.
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.
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
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.
Mostly through networked file system mounts with FSKit/FUSE backing when working on tasks in parallel. May be applicable for human facing tools but I think workflows there are already pretty set with having files locally and mounts need some lifecycles that agents are probably better at handling.
Crazy to see this thing on the front page of hacker news.
First off - I JUST started putting the site together and didn't expect any attention yet. So apologies for the bugs and mismatched content. Pull requests welcome at github.com/mrmrs/vimgifs :)
I created vimgifs because I have found gifs to be an effective way to help people learn vim commands. And I really like helping people become more efficient at building out their ideas.
The long term vision is to have a comprehensive set of examples that can be searched in a myriad of ways i.e related commands, all motion commands,all commands available in insert mode, .etc. If it's in :help I want a gif of it!
I don't have an opinion on whether or not vim is 'intuitive' but I will say it is much easier to learn than people make it out to be. I'd say it is infinitely less complex than whatever language you are trying to write in.
It took me less than a week to become more proficient in vim than in textmate - and I knew most of the command and shortcuts in textmate.
To people who say they don't have time to learn vim, a counter:
If you are pressed for time so much that you are debating whether or not you have time to learn something... it sounds like vim is definitely for you!
Vim isn't just about key strokes, commands, shortcuts, and the like. The more I learn about vim's capabilities the more I fundamentally think differently about editing and manipulating text. It has branching history, native ability to step through compile errors for ANY language, and navigation methods that truly changed how I think about exploring/navigating a code system. It's also ubiquitous which is pretty rad. I can't remember the last time I touched a computer that didn't have my favorite editor already installed.
I would encourage people not to denounce something they have never possessed. If you are not proficient in vim - it is difficult to denounce how intuitive it is. It's tough to denounce its ways and how much time they might save you.
I have become quite proficient in atom, sublime, textmate, and a few other editors. Even with 'vim mode' enabled these editors do not come close to the power that lies within vim.
But rest assured you can write amazing software with any text editor. I've met a lot of people who are excellent at writing code that never use vim and don't like it much.
In short - I hope this project makes it more fun and less intimidating to learn vim. I was lucky to have some amazing teachers when I got going and would love to pay their efforts forward a little bit.
Well I started designing the site a few hours ago so - it would make sense it has bugs and is out of sorts at the moment. Better information architecture is coming down the pipe for sure.
I would argue that .NET did allow for developers to be very productive at shipping the worst UI code I have ever seen. Productivity != shipping horrible code faster than ever. In my opinion.
