Hacker News: zdgeier

New comment by zdgeier in "Ask HN: Alternatives to GitHub"

zdgeier — Mon, 17 Aug 2026 17:27:10 +0000

We've added some things like CI, Windows support, and starting some work on path-based permissioning for monorepos. These are still in the early stages so not documented that great yet and need to be tested a little bit more. Should have more updates in the next couple weeks.

New comment by zdgeier in "Ask HN: Alternatives to GitHub"

zdgeier — Mon, 17 Aug 2026 15:00:55 +0000

I’m building a non-git alternative

https://oak.space

Would love for anyone to check it out!

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 20:05:23 +0000

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?

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 19:56:17 +0000

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!

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 19:55:06 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 19:52:06 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 03:54:51 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 03:51:55 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 02:12:13 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 01:15:39 +0000

A good tingle or bad tingle? haha

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Tue, 23 Jun 2026 01:15:04 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 23:41:22 +0000

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.

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 22:31:03 +0000

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

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 22:09:46 +0000

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

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 22:03:35 +0000

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

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 21:29:41 +0000

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!

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 21:13:17 +0000

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

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 20:51:39 +0000

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!

New comment by zdgeier in "Show HN: Oak – Git alternative designed for agents"

zdgeier — Mon, 22 Jun 2026 19:56:02 +0000

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

New comment by zdgeier in "Show HN: Oak – Git replacement designed for agents"

zdgeier — Mon, 22 Jun 2026 19:29:31 +0000

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!