alt.hn

2/15/2026 at 9:09:31 AM

SCM as a database for the code

 https://gist.github.com/gritzko/6e81b5391eacb585ae207f5e634db07e

by gritzko

2/15/2026 at 1:05:58 PM

We've tackled this problem slightly differently where I work. We have AI agents contribute in a large legacy codebase, and without proper guidance, the agents quickly get lost or reimplement existing functionality.

To help the agents understand the codebase, we indexed our code into a graph database using an AST, allowing the agent to easily find linked pages, features, databases, tests, etc from any one point in the code, which helped it produce much more accurate plans with less human intervention and guidance. This is combined with semantic search, where we've indexed the code based on our application's terminology, so when an agent is asked to investigate a task or bug for a specific feature, it'll find the place in the code that implements that feature, and can navigate the graph of dependencies from there to get the big picture.

We provide these tools to the coding agents via MCP and it has worked really well for us. Devs and QAs can find the blast radius of bugs and critical changes very quickly, and the first draft quality of AI generated plans requires much less feedback and corrections for larger changes.

In our case, I doubt that a general purpose AST would work as well. It might be better than a simple grep, especially for indirect dependencies or relationships. But IMO, it'd be far more interesting to start looking at application frameworks or even programming languages that provide this direct traversability out of the box. I remember when reading about Wasp[0] that I thought it would be interesting to see it go this way, and provide tooling specifically for AI agents.

[0] https://wasp.sh/

by hallh

2/16/2026 at 5:04:23 PM

This is close to what we're doing with [Encore](https://encore.cloud). The framework parses your application code through static analysis at compile time to build a full graph of services, APIs, databases, queues, cron jobs, and their dependencies. It uses that graph to provision infrastructure, generate architecture diagrams, API docs, and wire up observability automatically.

The interesting side effect is that AI tools get this traversability for free. When business logic and infrastructure declarations live in the same code, an AI agent doesn't need a separate graph database or MCP tool to understand what a service depends on or what infrastructure it needs. It's all in the type signatures. The agent generates standard TypeScript or Go, and the framework handles everything from there to running in production.

Our users see this work really well with AI agents as the agent can scaffold a complete service with databases and pub/sub, and it's deployable immediately because the framework already understands what the code needs.

by andout_

2/16/2026 at 4:22:20 AM

I’m currently experimenting with something similar on a smaller scale using continue.dev’s code indexing implementation to expose a context mcp server for both semantic and code search. Tricky part is of course context management.

by SOLAR_FIELDS

2/15/2026 at 10:31:57 AM

I think agree (but I think I think about this maybe a one level higher). I wrote about this a while ago in https://yoyo-code.com/programming-breakthroughs-we-need/#edi... .

One interesting thing I got in replies is Unison language (content adressed functions, function is defined by AST). Also, I recommend checking Dion language demo (experimental project which stores program as AST).

In general I think there's a missing piece between text and storage. Structural editing is likely a dead end, writing text seems superior, but storage format as text is just fundamentally problematic.

I think we need a good bridge that allows editing via text, but storage like structured database (I'd go as far as say relational database, maybe). This would unlock a lot of IDE-like features for simple programmatic usage, or manipulating langauge semantics in some interesting ways, but challenge is of course how to keep the mapping between textual input in shape.

by panstromek

2/15/2026 at 10:56:52 AM

Structural diff tools like difftastic[1] is a good middle ground and still underexplored IMO.

[1] https://github.com/Wilfred/difftastic

by fuhsnn

2/15/2026 at 11:17:25 AM

IntelliJ diffs are also really good, they are somewhat semi-structural I'd say. Not going as far as difftastic it seems (but I haven't use that one).

by panstromek

2/15/2026 at 10:19:32 PM 

  > Dion language demo (experimental project which stores program as AST).
Michael Franz [1] invented slim binaries [2] for the Oberon System. Slim binaries were program (or module) ASTs compressed with the some kind of LZ-family algorithm. At the time they were much more smaller than Java's JAR files, despite JAR being a ZIP archive.

[1] https://en.wikipedia.org/wiki/Michael_Franz#Research

[2] https://en.wikipedia.org/wiki/Oberon_(operating_system)#Plug...

I believe that this storage format is still in use in Oberon circles.

Yes, I am that old, I even correctly remembered Franz's last name. I thought then he was and still think he is a genius. ;)

by thesz

2/16/2026 at 6:21:58 AM

Interesting. It looks to me this was more about the portability of the resulting binary, IIUC.

Dion project was more about user interface to the programming language and unifying tools to use AST (or Typed AST?) as a source of truth instead of text and what that unlocks.

Dion demo is here: https://vimeo.com/485177664

by panstromek

2/16/2026 at 2:26:35 PM

I took a look.

Their system allow for intermediate state with errors. If that erroneous state can be stored to disk, they using a storage representation that is equivalent to text. If erroneous state cannot be stored, this makes Dion system much less usable, at least for me.

They also deliberately avoided pitfalls of languages like C. While they can do that because they can, I'd like to see how they will extend their concepts of user interface to the programming language and unifying tools to use (Typed) AST to C or, forgive me, C++, and what it'll unlock.

Also, there is an interesting approach of error correcting parsers: https://www.cs.tufts.edu/comp/150FP/archive/doaitse-swierstr...

Much extended version is in Haskell at Hackage: https://hackage.haskell.org/package/uu-parsinglib

As it allows monadic parsing combinators, it can parse context-sensitive grammars such as C.

It's interesting to see whether their demonstration around 08:30 of Visual Studio unable to recover from an error properly can be improved with error correction.

by thesz

2/15/2026 at 1:17:03 PM

I'm quite sure I've read your article before and I've thought about this one a lot. Not so much from GIT perspective, but about textual representation still being the "golden source" for what the program is when interpreted or compiled.

Of course text is so universal and allows for so many ways of editing that it's hard to give up. On the other hand, while text is great for input, it comes with overhead and core issues for (most are already in the article, but I'm writing them down anyway):

  1. Substitutions such as renaming a symbol where ensuring the correctness of the operation pretty much requires having parsed the text to a graph representation first, or letting go of the guarantee of correctness in the first place and performing plain text search/replace.
  2. Alternative representations requiring full and correct re-parsing such as:
  - overview of flow across functions
  - viewing graph based data structures, of which there tend to be many in a larger application
  - imports graph and so on...
  3. Querying structurally equivalent patterns when they have multiple equivalent textual representations and search in general being somewhat limited.
  4. Merging changes and diffs have fewer guarantees than compared to when merging graphs or trees.
  5. Correctness checks, such as cyclic imports, ensuring the validity of the program itself are all build-time unless the IDE has effectively a duplicate program graph being continuously parsed from the changes that is not equivalent to the eventual execution model.
  6. Execution and build speed is also a permanent overhead as applications grow when using text as the source. Yes, parsing methods are quite fast these days and the hardware is far better, but having a correct program graph is always faster than parsing, creating & verifying a new one.
I think input as text is a must-have to start with no matter what, but what if the parsing step was performed immediately on stop symbols rather than later and merged with the program graph immediately rather than during a separate build step?

Or what if it was like "staging" step? Eg, write a separate function that gets parsed into program model immediately, then try executing it and then merge to main program graph later that can perform all necessary checks to ensure the main program graph remains valid? I think it'd be more difficult to learn, but I think having these operations and a program graph as a database, would give so much when it comes to editing, verifying and maintaining more complex programs.

by flowerbreeze

2/16/2026 at 8:46:59 PM

> what if the parsing step was performed immediately on stop symbols rather than later and merged with the program graph immediately rather than during a separate build step?

I think this is the way to go, kinda like on Github, where you write markdown in the comments, but that is only used for input, after that it's merged into the system, all code-like constructs (links, references, images) are resolveed and from then you interact with the higher level concept (rendered comment with links and images).

For programinng langauge, Unison does this - you write one function at a time in something like a REPL and functions are saved in content addressed database.

> Or what if it was like "staging" step?

Yes, and I guess it'd have to go even deeper. The system should be able to represent broken program (in edited state), so conceptually it has to be something like a structured database for code which separates the user input from stored semantic representation and the final program.

IDE's like IntelliJ already build a program model like this and incrementally update it as you edit, they just have to work very hard to do it and that model is imperfect.

There's million issues to solve with this, though. It's a hard problem.

by panstromek

2/15/2026 at 11:05:40 AM

Why would structural editing be a dead end? It has nothing to do with storage format. At least the meaning of the term I am familiar with, is about how you navigate and manipulate semantic units of code, instead of manipulating characters of the code, for example pressing some shortcut keys to invert nesting of AST nodes, or wrap an expression inside another, or change the order of expressions, all at the pressing of a button or key combo. I think you might be referring to something else or a different definition of the term.

by zelphirkalt

2/15/2026 at 11:13:51 AM

I'm referring to UI interfaces that allow you to do structural editing only and usually only store the structural shape of the program (e.g. no whitespace or indentation). I think at this point nobody uses them for programming, it's pretty frustrating to use because it doesn't allow you to do edits that break the semantic text structure too much.

I guess the most used one is styles editor in chrome dev tools and that one is only really useful for small tweaks, even just adding new properties is already pretty frustrating experience.

[edit] otherwise I agree that structural editing a-la IDE shortcuts is useful, I use that a lot.

by panstromek

2/15/2026 at 1:00:08 PM

Some very bright Jetbrains folks were able to solve most of those issues. Check out their MPS IDE [1], its structured/projectional editing experience is in a class of its own.

[1] https://www.youtube.com/watch?v=uvCc0DFxG1s

by pegasus

2/15/2026 at 10:47:46 AM

Come the BABLR side. We have cookies!

In all seriousness this is being done. By me.

I would say structural editing is not a dead end, because as you mention projects like Unison and Smalltalk show us that storing structures is compatible with having syntax.

The real problem is that we need a common way of storing parse tree structures so that we can build a semantic editor that works on the syntax of many programming languages

by conartist6

2/15/2026 at 11:23:31 AM

I think neither Unison nor Smalltalk use structural editing, though.

[edit] on the level of a code in a function at least.

by panstromek

2/15/2026 at 12:39:59 PM

No, I know that. But we do have an example of something that does: the web browser.

by conartist6

2/15/2026 at 9:44:15 PM

> but storage format as text is just fundamentally problematic.

Why? The ast needs to be stored as bytes on disk anyways, what is problematic in having having those bytes be human-readable text?

by zokier

2/15/2026 at 10:34:00 AM

No we don't.

And you can build near any VCS of your dream while still using Git as storage backend, as it is database of a linked snapshots + metadata. Bonus benefit: it will work with existing tooling

The whole article is "I don't know how git works, let's make something from scratch"

by PunchyHamster

2/15/2026 at 10:55:48 AM

A syntax tree node does not fit into a git object. Too many children. This doesn't mean we shouldn't keep everything that's great about git in a next-gen solution, but it does mean that we'll have to build some new tools to experiment with features like semantic patching and merging.

Also I checked the author out and can confirm that they know how git works in detail.

by conartist6

2/15/2026 at 11:18:05 AM

Why do you think it has too many children? If we are talking direct descendents, I have seen way larger directories in file systems (git managed) than I've ever seen in an AST.

I don't think there's a limit in git. The structure might be a bit deep for git and thus some things might be unoptimized, but the shape is the same.

Tree.

by ongy

2/15/2026 at 1:02:49 PM

Directories use the `tree` object type in git whereas files use `blob`. What I understand you to suggest is using the tree nodes instead of the blob nodes as the primary type of data.

This is an interesting idea for how to reuse more of git's infrastructure, but it wouldn't be backwards compatible in the traditional sense either. If you checked out the contents of that repo you'd get every node in the syntax tree as a file, and let's just say that syntax nodes as directories aren't going to be compatible with any existing tools.

But even if I wanted to embrace it I still think I'd hit problems with the assumptions baked into the `tree` object type in git. Directories use a fundamentally different model than syntax trees do. Directories tend to look like `<Parent><Child/></>` while syntax trees tend to look like `<Person> child: <Person /> </>`. There's no room in git's `tree` objects to put the extra information you need, and eventually the exercise would just start to feel like putting a square peg in a round hole.

Instead of learning that I should use exactly git's data structure to preserve compatibility, I think my learning should be that a successful structure needs to be well-suited to the purpose it is being used for.

by conartist6

2/16/2026 at 12:09:08 AM

Your pseudo XML seems quite broken, since the supposed git style doesn't close the parent at all.

But the git directory entry contains: * a type (this one is quite limited, so I'm not sure how well that could be (ab)used * a name * a pointer to the content

Which is exaclty what an AST entry has.

by ongy

2/16/2026 at 3:51:37 AM

The pseudo-XML is a language I made called CSTML: https://docs.bablr.org/guides/cstml. I looked back and I don't see any unclosed tags, nor anything that would be an unclosed tag in XML either.

I'm sure you could abuse a git `tree` to squish in the extra data, but my point was just that you'd have to because a directory doesn't have a name that's separate from the name its parent uses to point to it. An AST node has both a name that its parent uses to point to it and an named identity e.g.:

``` <BinaryExpression> left: <Number '2' /> op: <'+'> right: <Number '2' /> </> ```

So my point is that to fit this into git you'd have to do something funky like make a folder called `left_Number`, and my question about this is the same question as I have in the first place about creating a folder on disk named `Number` whose contents are only the digit `2`. Since every existing tool will present the information as overwhelming amounts of nonsense compared to what users are used to seeing, has any compatibility at all been created? What was the point?

I also see the need to check out files as being an aspect of Git that relates purely to its integration with editors through flat text files. But if git was a more of a database than a filesystem then it's fair to assume that you'd prefer to integrate database access directly into the IDE.

by conartist6

2/16/2026 at 9:15:43 PM

but you can make a parallel branch with files parsed into ASTs (to have the most expensive path cached).

Then you can use alternative diff (which is pluggable, of course) to compare those ASTs, and quickly too.

Hell, you could generate those ASTs on server, making normal git client compatible, just unable to use this feature

by PunchyHamster

2/16/2026 at 9:24:31 PM

For anyone confused by this reply, the original title was

"Git is a file system. We need a database for the code"

Which begs the sequitur: "A database is just files in the file system. We need a database for the database"

by ASalazarMX

2/15/2026 at 10:16:23 AM

>I definitely reject the "git compatible" approach

If your version control system is not compatible with GitHub it will be dead on arrival. The value of allowing people to gradually adopt a new solution can not be understated. There is also value in being compatible with existing git integrations or scripts in projects build systems.

by charcircuit

2/15/2026 at 10:27:15 AM

Based on reading this, I don't see anything that would prevent keeping track of a repo tracked by this database with Git (and therefore GitHub) in addition to the database. I think the "compatible" bit means more that you have to think in terms of Git concepts everywhere.

Curious what the author thinks though, looks like it's posted by them.

by quadrifoliate

2/15/2026 at 10:54:01 AM

Technically, exporting changes either way is not a challenge. It only becomes difficult if we have multiple gateways for some reason.

One way to do it is to use the new system for the messy part and git/GitHub for "publication".

by gritzko

2/15/2026 at 9:20:36 PM

I don't think Git/GitHub is really all that big of a lock-in in practice for most projects.

IMO Git is not an unassailable juggernaut - I think if a new SCM came along and it had a frontend like GitHub and a VSCode plugin, that alone would be enough for a many users to adopt it (barring users who are heavy customers of GitHub Actions). It's just that nobody has decided to do this, since there's no money in it and most people are fine with Git.

by wavemode

2/15/2026 at 11:01:38 PM

The wall of getting buy in for switching your company over to a new SCM is much higher if you need to move everything over to a new system and switch over all of your developers onto new software at the same time. And if things don't work out you have to do the same expensive process in reverse. On the other hand if you have git compatibility you can start with a small group of developers being able to try out the tool first and see if it is actually beneficial and work your way spreading it through the company. If it turns out the new thing isn't good it is trivial to go back to your old tools since you did not have to do expensive migrations.

by charcircuit

2/16/2026 at 4:15:15 AM

I think you're right that this dynamic will exist of being harder to get buy-in all at once, but git faced that dynamic when competing against earlier VCS systems and still won the market.

The dynamic that I think balances this out is the "inherited expectations" dynamic. You'll end up winning a lot of people by offering them easy migration, but then you'll find it difficult or impossible to satisfy them because they just want the exact same product they were using but somehow magically cheaper and better.

My goal is to avoid the violent, priority-changing growth that comes with direct interoperability, and just ride the regular bell-shaped adoption curve.

Right now I want to connecting with early adopters who are eager to look at a new technology precisely because they're crashing up against the more immovable limitations of the old and so who are willing to seek out and accept new things, even if it means accepting change. But that acceptance of change is key to creating expectations I can actually satisfy so that my growth actually drives more growth

by conartist6

2/15/2026 at 10:27:34 AM

A system as described could be forwards compatible with git without being backwards compatible with git. In other words let people migrate easily, but don't force the new system to have all the same flaws of the old

by conartist6

2/15/2026 at 10:57:36 AM

What issues do you see in git's data model to abandon it as wire format for syncing?

by ongy

2/15/2026 at 11:03:47 AM

I wouldn't say I want to abandon anything git is doing as much as evolve it. Objects need to be able to contain syntax tree nodes, and patches need to be able to target changes to particular locations in a syntax tree instead of just by line/col.

by conartist6

2/15/2026 at 11:20:08 AM

An AST is a tree as much as the directory structure currently encoded in git.

It shouldn't be hard to build a bijective mapping between a file system and AST.

by ongy

2/15/2026 at 1:11:41 PM

Right, but for what purpose? I don't see much gain, and now you're left trying to fit a square peg into a round hole. The git CLI would be technically working, but not practically useful. Same with an IDE: if you checked the files out you could technically open them but not easily change your program.

by conartist6

2/15/2026 at 11:59:33 PM

the git server would continue to work.

The cli really isn't the greatest either way. But there's lots of infrastructure to make the sharing work reasonably well.

by ongy

2/16/2026 at 4:01:52 AM

You could also think of it this way: if I abuse git's protocols to do my thing, I pretty much give up my chance to become a standard in the future. If people are going to adopt a new standard they want it to be clean: you don't want to be trying to sell a greenfield technology that's loaded up with legacy tech debt. Making a data format that renders broken in every existing tool that touches it would be showing a lot of bad faith up front.

by conartist6

2/16/2026 at 12:31:32 AM

Doesn't seem like they want VCS in traditional sense anyway. More like a collaborative undo history with emphasis on CRDT?

by ivanjermakov

2/16/2026 at 5:31:21 PM

A CRDT-like approach to version control is usable today in darcs and pijul. Neither of them currently have a database for backend, though, but exploring both as alternatives to git and alternative's to git's ideas/dominance is still a handy idea.

by WorldMaker

2/15/2026 at 10:35:06 AM

I've had this idea too, and think about it everytime I'm on a PR with lots of whitespace/non-functional noise how nice it would be if source code wern't just text and I could be looking at a cleaner higher level diff instead.. I think you have to go higher than AST though, it should at least be language-aware

by gfody

2/15/2026 at 10:40:26 AM

(Author) In my current codebase, I preserve the whitespace nodes. Whitespace changes would not affect the other nodes though. My first attempt to recover whitespace algorithmically not exactly failed, but more like I was unable to verify it is OK enough. We clang-format or go fmt the entire thing anyway, and whitespace changes are mostly noise, but I did not find 100% sure approach yet.

by gritzko

2/15/2026 at 8:53:49 PM

I think about eg the "using" section at the top of a .cs file where order doesn't matter and it's common for folks to use the "Remove and Sort Usings" feature in VS.. if that were modeled as a set then diffs would consist only of added/removed items and a re-ordering wouldn't even be representable. And then every other manner of refactor that noises up a PR: renaming stuff, moving code around, etc. in my fantasies some perfect high-level model would separate everything that matters from everything that doesn't and when viewing PRs or change history we could tick "ignore superficial changes" to cut thru all the noise when looking for something specific

..to my mind such a thing could only be language-specific and the model for C# is probably something similar to Roslyn's interior (it keeps "trivia" nodes separate but still models the using section as a list for some reason) and having it all in a queryable database would be glorious for change analysis

by gfody

2/16/2026 at 5:29:17 PM

In my investigations ages ago [1] I felt the trick was to go lower that an AST. ASTs by nature generally have to be language-aware and vary so much from language to language that trying to generally diff them is rough. I didn't solve the language-aware part, but I did have some really good luck with using tokenizers intended for syntax highlighting. Because they are intended for syntax highlighting they are fast, efficient, and generally work well with "malformed"/in-progress works (which is what you want for source control where saving in progress steps can be important/useful/necessary).

It still needs to be language-aware to know which token grammar to use, but syntax highlighting as a field has a relatively well defined shared vocabulary of output token types, which lends to some flexibility in changing the language on the fly with somewhat minimal shifts (particularly things like JS to TS where the base grammars share a lot of tokens).

I didn't do much more with it than generate simple character-based diffs that seemed like improvements of comparative line-based diffs, but I got interesting results in my experiments and beat some simple benchmarks in comparing to other character-based diff tools of the time.

(That experiment was done in the context of darcs exploring character-based diffs as a way to improve its CRDT-like source control. I still don't think darcs has the proposed character-based patch type. In theory, I could update the experiment and attempt to use it as a git mergetool, but I don't know if it provides as many benefits as a git mergetool than it might in a patch theory VCS like darcs or pijul.)

[1] https://github.com/WorldMaker/tokdiff

by WorldMaker

2/15/2026 at 11:19:00 AM

Some languages are unfortunately whitespace sensitive, so a generic VCS cannot discard whitespace at all. But maybe the diffing tools themselves could be made language aware and hide not meaningful changes.

by zelphirkalt

2/15/2026 at 3:41:30 PM

hiding not meaningful changes is not enough. when a block in python changes the indentation, i want to see that the block is otherwise unchanged. so indentation changes simply need to be marked differently. if a tool can to that then it will also work with code where indentation is optional, allowing me to cleanly indent code without messing up the diff.

i saw a diff tool that marked only the characters that changed. that would work here.

by em-bee

2/16/2026 at 2:49:11 PM

Both svn and git have command line options for diff to hide whitespace changes. It's always disappointed me that various web UIs don't have a toggle for it.

by Izkata

2/16/2026 at 3:25:48 PM

hiding whitespace changes is not the same as indicating them as whitespace change. in particular hiding messes up the proper display of indentation, so it's not always useful.

by em-bee

2/15/2026 at 8:54:01 PM

Git works universally as a storage backend, with some reasoning capacity thanks to commit history. It didn't need to include semantics about the code or build a tree of knowledge. That would be against Linux philosophy: Do one thing and do it well.

You can build whatever you want on top to help your AI agents. That would be actually beneficial so that we stop feeding raw text to this insane machinery for once.

by moezd

2/15/2026 at 11:02:38 AM

Somebody call the visualage and clearcase folks and let them know their time has come again!

by DannyBee

2/15/2026 at 11:06:41 AM

> clear case

Please no.

by guerrilla

2/15/2026 at 12:13:27 PM

What, you dont like 6 hour code checkouts of 10 megabyte projects?

All you had to do was access it over VPN and you could go on vacation because nobody would expect you to get anything done!

by DannyBee

2/15/2026 at 12:32:48 PM

That's what I remember most about it: how much it lowered expectations on us. We barely ever worked because most of the time we couldn't. It was always broken (not just slow). This became a part of the culture where management didn't even care what we did. They knew eventually things would get done (late) but we'd also have to wait. That was just part of it.

by guerrilla

2/15/2026 at 1:24:15 PM

I agree. I will say the slowness i could kind of understand - just poor network protocol optimization/etc on their part, etc. Not that i excused it, but i at least could understand how you get there - you are always on a fast network and so you just don't notice what it's like when you aren't.

The brokeness was always what got me. I had to believe either they had no unit tests, or 1000's of them were failing and they released it anyway. Because it was so fragile that it would have been impossible to test it and not notice easily broken things.

by DannyBee

2/15/2026 at 10:24:46 AM

> The monorepo problem: git has difficulty dividing the codebase into modules and joining them back

Can anyone explain this one? I use monorepos everyday and although tools like precommit can get a bit messy, I've never found git itself to be the issue?

by benrutter

2/15/2026 at 10:34:39 AM

Based on my personal experience, big-corp monorepos have all features of a black hole: they try to suck in all the existing code (vendor it) and once some code starts living in a monorepo, there is no way to separate it as it becomes entangled with the entire thing. There is no way to "blend it in", so to say.

This subject deserves a study of its own, but big-big-tech tends to use other things than git.

by gritzko

2/15/2026 at 11:09:29 AM

That black hole behavior is a result of corporate processes though.

Not a result of git.

Business continuity (no uncontrolled external dependencies) and corporate security teams wanting to be able to scan everything. Also wanting to update everyone's dependencies when they backport something.

Once you got those requirements, most of the benefits of multi-repo / roundtripping over releases just don't hold anymore.

The entanglement can be stronger, but if teams build clean APIs it's no harder than removing it from a cluster of individual repositories. That might be a pretty load bearing if though.

by ongy

2/15/2026 at 11:44:58 AM

> there is no way to separate it

There is

git subtree --help

May get complicated at the edges, as files move across boundaries. It's a hard problem. And for some subset of those problems, subtree does give a way to split and join.

by rbsmith

2/15/2026 at 3:10:05 PM

I think a lot of people misunderstand what git really is for large software organizations. It's not their version control system. It's the set of primitives on top of which their version control is built.

Monorepos are one such VCS, which personally I don't like, but that's just me. Otherwise there are plenty of large organizations that manage lots of git repositories in various ways.

Replacing git is a lot like saying we should replace Unix. Like, yeah, it's got its problems, but we're kind of stuck with it.

by EPWN3D

2/15/2026 at 10:41:23 AM

Let's say I want to fork one of your monorepo modules and maintain a version for myself. It's hard. I might have to fork 20 modules and 19 will be unwanted. They'll be deleted, go stale, or I'll have to do pointless work to keep them up to date. Either way the fork and merge model that drives OSS value creation is damaged when what should be small, lightweight focused repos are permanently chained to the weight of arbitrary other code, which from the perspective of the one thing I want to work on is dead weight.

You can also just tell that monorepos don't scale because eventually if you keep consolidating over many generations, all the code in the world would be in just one or two repos. Then these repos would be so massive that just breaking off a little independent piece to be able to work on would be quite crucial to being able to make progress.

That's why the alternative to monorepos are multirepos. Git handles multirepos with it's submodules feature. Submodules are a great idea in theory, offering git repos the same level of composability in your deps that a modern package manager offers. But unfortunately submodules are so awful in practice so that people cram all their code into one repo just to avoid having to use the submodule feature for the exact thing it was meant to be used for...

by conartist6

2/15/2026 at 11:27:59 AM

Hm, I never had much issues with submodules. It seems just to be something that when one has understood it, one can use it, but it might seem scary at first and one needs to know, that a repo uses submodules at all.

by zelphirkalt

2/15/2026 at 1:05:18 PM

Submodule-based multirepos still have a tiny fraction of the adoption that monorepos do. Tooling support is quite poor by comparison.

by conartist6

2/15/2026 at 10:46:52 AM

For example there is no easy way to create a "localized" branch - this branch is only allowed to change files in "/backend", such that the agent doesn't randomly modify files elsewhere. This way you could let an agent loose on some subpart of the monorepo and not worry that it will break something unrelated.

You can do all kinds of workarounds and sandboxes, but it would be nice for git to support more modularity.

by dist-epoch

2/15/2026 at 11:42:25 AM

Sounds like a submodule with restrictions for push access managed on the repo level of the submodule.

by zelphirkalt

2/15/2026 at 10:35:26 AM

The author doesn't know how to use git or how git works.

If he knew how to use it, he'd be annoyed at some edge cases.

If he knew how it works, he'd know the storage subsystem is flexible enough to implement any kind of new VCS on top of it. The storage format doesn't need to change to improve/replace the user facing part

by PunchyHamster

2/15/2026 at 10:42:44 AM

Joe Armstrong had a beautiful LEGO vs Meccano metaphor. Both things are cool and somewhat similar in their basic idea, but you cannot do with LEGO what you can do with Meccano and vice-versa. Also, you can not mix them.

by gritzko

2/16/2026 at 9:13:08 PM

Git has like million adapters, and to things that barely relate to VPS, I used it to edit mediawiki pages

by PunchyHamster

2/15/2026 at 11:40:46 AM

But you could create some parts that are enabling you to combine them easily. Which is what you could do with software. Write an adapter of sorts.

by zelphirkalt

2/15/2026 at 11:02:46 AM

Sure you can. Hot glue, E6000, duct tape. This is to say, git's pack format has its shortcomings.

by fragmede

2/15/2026 at 10:57:59 AM

A big challenge will be the unfamiliarity of such a new system. Many people have found that coding agents work really well with terminals, unix tooling, and file systems. It's proven tech.

Where-as doing DB queries to navigate code would be quite unfamiliar.

by whazor

2/15/2026 at 11:25:30 AM

One fundamental deal-breaking problem with structure aware version control is that your vcs now needs to know all the versions of all the languages you're writing in. It gets non-trivial fast.

by procaryote

2/15/2026 at 2:09:41 PM

It does! So extensible parser definition is another key piece of the technological puzzle along with common formats for parse trees.

by conartist6

2/15/2026 at 11:06:31 AM

To me, git works. And LLMs understand that, unlike some yet-to-come-tool.

If you create a new tool for version control, go for it. Then see how it fares in benchmarks (for end-to-end tools) or vox populi - if people use you new tool/skill/workflow.

by stared

2/15/2026 at 10:05:09 AM

I’ve recently been thinking about this too, here is my idea: https://clintonboys.com/projects/lit/

by mtsolitary

2/15/2026 at 10:53:34 AM

Using prompt as source of truth is not reliable, because outputs for the same prompt may vary

by ferroman

2/15/2026 at 11:12:28 AM

Of course. But if this is the direction we’re going in, we need to try and do something no? Did you read the post I linked?

by mtsolitary

2/15/2026 at 10:30:51 AM

> Like everyone else with a keyboard, a brain and a vested interest in their future as a programmer, I’ve been using AI agents to write a lot of code recently.

alrighty then..

by gethly

2/15/2026 at 10:09:32 AM

Talk is cheap. Show me the code.

by solarized

2/15/2026 at 10:47:54 AM

No, we don’t. The genius of git is in its simplicity (while also being pretty damn complicated too).

by deafpolygon

2/15/2026 at 10:05:47 AM

Missing 4 out of 5 parts. The attempt to wrest control away from the open source community doesn't even have the effort to keep going.

by sublinear

2/15/2026 at 10:29:47 AM

The gist was created 1 hour before your comment.

by bonzini

2/15/2026 at 10:09:35 AM

Yes, parts will keep coming, this weekend and the next week.

by gritzko

2/15/2026 at 10:15:29 AM

[dead]

by hole_in_foot

2/15/2026 at 10:51:15 AM

[dead]

by OhNoNotAgain_99

2/15/2026 at 10:07:07 AM

Definitely agree that Git is mediocre-at-best VCS tool. This has always been the case. But LLMs are finally forcing the issue. It’s a shame a whole generation programmers has only used Git/GitHub and think it’s good.

Monorepo and large binary file support is TheWay. A good cross-platform virtual file system (VFS) is necessary; a good open source one doesn’t exist today.

Ideally it comes with a copy-on-write system for cross-repo blob caching. But I suppose that’s optional. It lets you commit toolchains for open source projects which is a dream of mine.

Not sure I agree that LSP like features need to be built in. That feels wrong. That’s just a layer on top.

Do think that agent prompts/plans/summaries need to be a first class part of commits/merges. Not sure the full set of features required here.

by forrestthewoods

2/15/2026 at 10:22:30 AM

> It’s a shame a whole generation programmers has only used Git/GitHub and think it’s good.

Well... I used SVN before that and it was way worse.

by JodieBenitez

2/15/2026 at 11:02:24 AM

Clearly the poster has never encountered cvs or cvs-next.

And clear OP hasn't heard of vss..

by ryanm101

2/15/2026 at 12:21:01 PM

Where I worked, before SVN we didn't even used any VCS system. Most of us were not even familiar with the concept.

by JodieBenitez

2/15/2026 at 9:16:39 PM

I have worked with all those and more.

by forrestthewoods

2/15/2026 at 11:11:48 AM

RCS, anyone?

by fragmede

2/15/2026 at 10:37:37 AM

Continuing the theme, a new starter at my place (with about a decade of various experience, including an international financial services information player whose name is well known) had never used git or indeed any distributed, modern source control system.

HN is a tiny bubble. The majority of the world's software engineers are barely using source control, don't do code reviews, don't have continuous build systems, don't have configuration controlled release versions, don't do almost anything that most of HN's visitors think are the basic table stakes just to conduct software engineering.

by EliRivers

2/15/2026 at 10:57:02 AM

> It lets you commit toolchains

Wasn't this done by IBM in the past? Rational Rose something?

by dist-epoch

2/15/2026 at 11:04:01 AM

Clearcase

by DannyBee