Posted by zdgeier 1 day ago
Oak is still early in development. There's no Windows build and missing plenty of features (no CI, no issues, no comments). We still use GitHub Actions for building Oak now, but we've been fully bootstrapped on Oak with no Git backup for several months: https://oak.space/oak/oak.
Blog post: https://oak.space/blog#git-is-forever
Docs: https://oak.space/docs
how does your agent run tests or click around the UI to verify changes if it doesn't have the full code?
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.
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.
There's plenty of workarounds too, but that's what they are. Workarounds.
With other backends, it inherits their problems. But also their solutions :) So with those backends, it could!
2. rebase based merge strategies - our team has 50+ devs across three continents merging into monorepo with teams maintaining submodules. By the time your merge request passes CI it has to be rebased. People are literally holding off on reviewing merge requests to make sure their own changes get in first
3. permissions for subdirectories/assets. some necessary code/modules are highly regulated and company secrets. Git cant lock certain directories based on who clones the repo
4. Agentic coding - if you don't commit then your changeset after each request is lost. JJ solves this. You could just say to commit after every request then squash the commits. But, I think this is an ergonomic argument
5. Maybe it's just my experience, but git-lfs is pretty annoying to manage on large teams and changing files to/from lfs. often easier to just delete and clone again
6. git blame on non-meaninful changes. Running a code linter to add/remove whitespace makes git blame return who ran the linter rather than who wrote the code
7. self-reported identity. every time we get new laptops (because they buy the cheapest POS) devs forget what they set for 'username'. so it ends up being 3-4 different identities with the same email
Those are just my complaints lately
2. That has the smells of a wrong code architecture. If change request leads to unneeded code conflicts, you need to rework your code architecture.
3. That’s valid, but why not create libraries out of those modules?
4. Valid. But I think the issue is on the agent side. Git has already all the features to make those happen, it’s the agent that is not integrated with git.
5…
6. Either than sweeping changes (adding a formatter, changing config,…) There’s no need for formatting changes to be its own commit in the main repo. I usually add a check to prevent inconsistent formatting.
7. The git history has the previous username and email recorded alongside each commit.
(Compare to Mercurial, Fossil or Git; those systems have consistent and usable interfaces. There's much less demand for wrappers or LLM tooling since they're easy to use already.)
2. Preservation of history. Two common commands - git rebate and git push -f - cause commit history to be lost, sometimes permanently. ("Just be careful" and "Just don't use those commands" are useful pieces of advice for an individual, and virtually impossible to enforce over groups.)
3. Conflict resolution. Git forces the user to resolve conflicts ASAP so we often lose information about A. What the conflict exactly was, and B. How the individual resolved it. Most VCS have this issue; JJ allows you to commit the conflict and solve it in a separate commit, which is nice.
2. https://git-scm.com/docs/git-reflog
It’s very hard to loose data in git.
3. The goal of writing code is to have working software. Conflict messages are like compiler warnings, better have them than getting errors slipping by unnoticed. If A conflict with B, the root cause is often a design conflict, which means that the design of the software is inconsistent.
The conflict only matters as long as it’s not been solved. For each commit, the design of the software need to be consistent, and the succession of commit describe the evolution of the design. A is not lost, B is not lost in the case of a merge and may stay for a long time when rebasing. C which solves the difference between A and B (and may replace B) is also consistent. I don’t care about inconsistency.
* monorepo megarepos - but you kinda need system built from scratch that sacrifices a lot in other places to handle that in the first place * media asset heavy repositories - again, different paradigm. Stuff that make Git great like full local history just become impossible to do sensibly when amount of changes per day is hundreds of megabytes.
Most projects don't git that. And for majority git + LFS is enough.
> 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?
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.
> 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"?
That said, it hasn't been enough of an issue for me to want to fix.
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.