Tools: Free Git Is A File System. We Need A Database For The Code 2026
Software development is changing rapidly and the tool stack has yet to catch up. As we see, the value of IDEs diminishes as developers are less inclined to edit the code now. More and more of the work is browsing and talking to LLMs, less and less is coding and debugging. About 8 years ago I gave a talk at the internal JetBrains conference "Code is hypertext, IDE is a browser". Those points look even more relevant now: effective browsing of code and history is a prerequisite to effective understanding. Understanding underlies everything now. No understanding = no control, then a developer is like a rider who fell off a LLM horse with his foot caught in the stirrup (you may search YouTube to understand what I mean).
git is increasingly becoming a point of friction. LLMs have high throughput in regard to code edits. Sorting out the changes then takes disproportionate time and often repeats your previous work, if you actually read the diffs during the session, which I highly recommend. Even single-person development now becomes collaborative: at the very least, your collaborator is an LLM. In calm waters, running several agents is nothing special. Then I have an entire team, with all the merges and rebases (which we like to do beyond any measure).
That is why I think it is the right time to look for git replacements, and that is why I am working on one. I definitely reject the "git compatible" approach despite the immense gravitation of the existing mass of git repos. jj to git is what subversion was to cvs. What we need is what git was to cvs: a level-up. All the long-standing and all the new issues are all rooted in the core architecture of git. In any other case, those issues would be fixed by now just by gradual and incremental improvement.
The monorepo problem: git has difficulty dividing the codebase into modules and joining them back. Apart from the fact that git submodules have been improvised clumsily and haunt us ever since, the very conceptual approach to splitting and joining the code is lacking. All the Big-monorepo companies either use something else or build on top of git.
The split/join problem has way more implications. Suppose, for example, I want to keep my prompts and plans in a separate repo, but join them in when necessary. Or, go full JTPP - "just the prompt, please". Git has no solution for such "overlay branches", in principle. There is a source tree in git, there is a build tree somewhere else, and there is a prompt/todo/plan tr
Source: HackerNews
