nickg-anthropic

Just because you might find this interesting: Scion deviates significantly in this regard in order to deal with merges; coming from git, we land code to our main branch via merge so it's a common occurrence.

We do discourage (but not block) some trickier DAG things you could have done in git and are probably moving towards squashing and rebasing for landing since many things become simpler without merges, but we simply had to deal with merges (and handle git compatibility while migrating) to pull this off. Particularly, full DAG merge bases add a lot of complexity and it gave us some concrete ideas on how to improve git's commit graph data structures by an order of magnitude or more.

Very little, overall.

This system was actually built incrementally over several months and did not start out as a full VCS -- it started as a read-only service that ingested data from our Git repo to take pressure off of CI and other tools needing to materialize checkouts for certain types of repo/graph questions. Even when we did decide to go all the way, we were operating in a hybrid Git/Scion world for months during the migration and the path to get there made the system and code very unique to our infrastructure.

I don't use HN often, so I made an account for this purpose that would make it clear who I was in relation to the article.

The point explicitly isn't that you should vibe-code your own VCS. There are a lot of ideas here that would be directly applicable to git, for example, and we are working to share the learnings with the right companies and maintainers.

If you're referring to this part: > This does mean that concurrent changes can conflict, but Claude can typically fix these conflicts faster than humans can even identify them.

We never allow textual conflicts, but semantic conflicts (for example, if someone adds changes the logic of a function and cleans up all affected callsites concurrently with a new call being added) are an unavoidable fact of very large repos unless you completely serialize merging with running extensive validation at the proposed batch tip, which isn't practical at a certain commit rate.

As for cross-repo changes, not exactly, but there are ways we could allow such a thing if we wanted. We're thinking about it.

Of course! The point is that it is a non-starter to operate this way but git doesn't hold your hand to do the right thing here. Everyone probably lands on approximately similar solutions with varying degrees of sophistication (which is something that could probably be improved in the ecosystem!) and even those common patterns stopped working for us as the repo continued to grow.

That's true, but logistically speaking the way that git wants data to exist on disk makes it very, very hard to do the kinds of things we needed to do given how many nodes we have that need source code and how quickly the repo is growing. We do have some ideas on how this can be improved upstream!

Building all of the systems to train and serve our models, internal tools and infrastructure, (lots and lots of) research, our product and API surfaces, and more. We have a lot of problems that we can solve with code and there are all sorts of new projects spinning up every week.

It sounds like it would be simple, but there are a lot of logistical issues with making git happy with this in practice. Repacking things for repo maintenance, for example, but there are many other problems.

The changeset and tree manifests are still a Merkle tree in the ways that matter (i.e., it's all immutable, content-addressed, verifiable if you were so inclined), the client just doesn't need the entire thing locally.

There actually was lot more hand-writing of the code back then! Or, at least, only moderately assisted by Claude with a lot of human-still-typing-things-in-an-editor. The ability to delegate larger chunks of code to Claude had a noticeable, step function increase with Mythos Preview.

A monorepo gives us a really consistent tooling floor where everything more or less works in a uniform way. We've had a lot of success with it, in general, and it gives us a lot of leverage in the sense that we can make a sweeping change in one atomic commit rather than have to run a campaign across hundreds or thousands of repos, all with their own norms and tools.

It actually scales by "going wider" and being able to do more things rather than iterating on the same code over and over again. If you can only write X amount of code per day because of some limitation (human attention, source control, CI, whatever it is), you would of course use that energy on the highest priority and highest value work. As we remove scaling issues in source control, for example, we can just "do more things" without worrying about bringing down infrastructure.