Live data from Hacker News

Show HN: Oak – Git alternative designed for agents

oak.space

61–70 of 216 posts

Re: Show HN: Oak – Git alternative designed for agents

#61
post #38

Earlier quoted context omitted.

What is git not suited for in modern development? I haven't found any reasons.

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 an…

to be fair, #2 exists because monorepos and submodules are somewhat antithetical concepts. A monorepo is supposed tobe the single source of truth for the codebase, while submodules are pointers to external repos with their own history. That alone will increase the source of churn for teams that are constantly merging.

Re: Show HN: Oak – Git alternative designed for agents

#63
post #6

Earlier quoted context omitted.

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…

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.

Re: Show HN: Oak – Git alternative designed for agents

#64
post #19

Earlier quoted context omitted.

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

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.

Re: Show HN: Oak – Git alternative designed for agents

#65

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.

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-...

Re: Show HN: Oak – Git alternative designed for agents

#66
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."

Re: Show HN: Oak – Git alternative designed for agents

#67
post #38

Earlier quoted context omitted.

What is git not suited for in modern development? I haven't found any reasons.

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 an…

1. git rebase and last commit amending.

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.

Re: Show HN: Oak – Git alternative designed for agents

#68
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

Re: Show HN: Oak – Git alternative designed for agents

#69
post #46

Earlier quoted context omitted.

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.

You're diffing very large assets?

Re: Show HN: Oak – Git alternative designed for agents

#70

Did you have your agent talk you into making this something separate over building on top of git?

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.
Post reply on HN