I've built my own workflow for using agents on git, as i know 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.
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.
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.)
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.
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.
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.
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.
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.
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
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
1. Ease of use. Other VCS have more consistent command line interfaces; Git's interface has to be studied. In practice, people end up using GUIs with missing functionality and then end up searching for help, and a lot of real experts come to rely on powerful wrappers like Magit, LazyGit, or JJ.
(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.
How’s it an ill fit? Outside of large monorepo things, which are not the majority of modern commercial software projects, the main complaint I hear is the learning curve. But LLMs should be addressing that fairly well.
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.
"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.
> "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.
1) An “easy” way to implement this would be to treat the original file as the parent to both files. You can add a new command “split” if needed to mark the new file as a fork of the existing file.
2) language sensitive version control seems like the next thing. We need like an LSP for VCSes.
If I run blame on the new file the will I see the commits made by the original writers? Will it find the same code if it was written independently? It’s not about find copies it about recording changes to a code base as an artifact and not to files. The closest git has is limited rename support.
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!
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.
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.
* 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."
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.
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.
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). 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.
I've built my own workflow for using agents on git, as i know 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
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
Zed’s DeltaDB is that very idea I believe
https://zed.dev/deltadb
Jujutsu might be what you’re looking for then.
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
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.
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.
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.
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.)
> designed for your agents
And there we go.
"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.
What is git not suited for in modern development? I haven't found any reasons.
Game development, with very large assets. Also, git is pretty terrible with non-text files.
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.
Do you know if Jujutsu addresses these issues?
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
1. rewriting history
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
Armin and Ben did a nice deepdive on Mercurial vs Git and why hg should have won in a recent episode of their "nerds-chatting" style podcast: https://www.youtube.com/watch?v=JM1sIVIZYRg&t=3813s
1. Ease of use. Other VCS have more consistent command line interfaces; Git's interface has to be studied. In practice, people end up using GUIs with missing functionality and then end up searching for help, and a lot of real experts come to rely on powerful wrappers like Magit, LazyGit, or JJ.
(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.
How’s it an ill fit? Outside of large monorepo things, which are not the majority of modern commercial software projects, the main complaint I hear is the learning curve. But LLMs should be addressing that fairly well.
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.
"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.
> "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.
The other way is to make the tool UX do the semantic, ie:
`git split`
Something that I enjoy with jujutsu is that the semantics is the tool itself. ONCE you do that, the rest become easier!
1) An “easy” way to implement this would be to treat the original file as the parent to both files. You can add a new command “split” if needed to mark the new file as a fork of the existing file.
2) language sensitive version control seems like the next thing. We need like an LSP for VCSes.
git actually does this. `git diff --find-copies`
If I run blame on the new file the will I see the commits made by the original writers? Will it find the same code if it was written independently? It’s not about find copies it about recording changes to a code base as an artifact and not to files. The closest git has is limited rename support.
Yes, if you run `git blame -C`.
Grammar nitpick: "anyways" should almost awlays be "anyway"
https://www.merriam-webster.com/dictionary/anyways
"awlays" should almost always be "always"
Does this try to solve the biggest problems with Git: submodules and LFS?
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!
> 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?
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.
This sounds similar to Epic Games' Lore approach - have you seen what they're doing?
https://epicgames.github.io/lore/explanation/system-design/ if not
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.
you don't need to replace, you just need to find your niche, then expand from there
VCS is just about the last type of vibe-coded software I would ever trust.
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"?
Yeah, I'll just wait for jj to get more virtualized FS features, and be very, very happy with that.
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."
"I built a version control system, in my free-time, called Jam" is fine.
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.
It's also fine without the commas, because nobody was confused by that structure.
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.
Check out the homepage! https://oak.space might have what you're looking for. I can answer any questions you have here as well.
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). 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.
The blog post is a terrible intro, the website is much more insightful: https://oak.space/
I found the section titled “Local feature branches. Server main. One squash.” most interesting.