Linus wrote Git in about 10 days, so I asked my local LLM to build something similar with one prompt

Published Oct 5, 2026, 2:00 PM EDT Richard is the PC Hardware Lead at XDA and has been covering the technology industry for almost two decades. He's been building PCs since young, and when not creating content, you can often find him inside a chassis somewhere. I've been toying around with running large language models (LLMs) at home with an RX 7900 XT and a whopping 20 GB of VRAM, which isn't much when considering some of the hardware options for AI development. I've used an LLM to build apps, websites, scripts, short story outlines, images, extended design briefs, and more. But I wanted to see how far I could push it in new ways, so I tasked one with building Git. Not a GitHub alternative ( Gitea is brilliant for that), but my own version control system with a repo, snapshots, everything. Linus created Git in 10 days. My LLM managed to pull it off in a few hours. I'm not trying to best Linus Git is the gold standard of version control There's really no need to leave a comment like "This isn't as good as Git, you fool," as that's not what I wanted to create. I didn't want something that I would openly use, promote, and sell for a $4.99 subscription. Git has been around for a while now, and there has been plenty of refinement, edge cases, and compatibility that a local LLM simply cannot account for without considerable development time and hundreds of carefully guided prompts. What my LLM can do is take publicly available knowledge and design work to create something similar in record time. I wanted something created with the core concept of Git as a version control system (VCS). It would have a repository initialized, the ability for file contents to be stored as immutable objects, provide the means to identify objects using hashes, allow for snapshots and commits, maintain a pointer to the most recent commit, and inspect the full commit history (with the option to restore files from an earlier commit). It sounds basic as a design brief, and that's the beauty of Git. It really is simple but incredibly effective. There were some challenges for the LLM. It had no net access. No API to call upon. It couldn't invoke the locally installed git system, and I wouldn't intervene with any alterations or corrections. The LLM would have to write the code, check it, and correct any detected issues. I was simply going to prompt it at each stage. The model in question is qwen3.6:27b_Q4_K_M. The model is running on Ollama (with Open WebUI), on an AMD Threadripper server with the aforementioned RX 7900 XT routed through the LXC. The goal was to have everything in place with a single prompt. Build a small Git-like VCS in /opt/qwen-workspace/tinyvcs.Use Python standard library only.Do not call git.Store metadata in .tinyvcs.Required commands:- init- commit -m MESSAGE- log- status- checkout COMMITRequirements:- recursive snapshots- binary-safe- SHA-256 deterministic commit IDs- parent links- added/modified/deleted status- checkout restores exact tracked state- refuse checkout if it would overwrite uncommitted work- corrupt metadata must error cleanlyCreate:- tinyvcs.py- README.md- DEVLOG.mdActually run and test:- normal text file- modified file- deleted file- new file- filename with spaces- empty file- binary file- nested directory- invalid checkout- uncommitted checkout refusal- corrupted metadataDo not explain the implementation before acting.Use tools immediately.After each tool call, continue to the next step until the project is complete. I didn't plan to intervene unless it had a question, claimed to have finished the work, or started losing its marbles. It needed a little hand-holding Likely down to Open WebUI more than anything I wanted to keep things simple. Stick to the Open WebUI platform with Ollama integration since that's largely what people self-host and enjoy using. I've used it extensively and find it to be a solid offering for running local models. Open Terminal was already added and ready to go too, so Qwen had everything it needed to get the job done. Interestingly, the model immediately found issues after the first code pass in generating a VCS. "Several issues to fix. The _collect_files function has a bug with .tinyvcs pruning, and the commit comparison logic." Not a bad start at all. After a few more runs, it encountered an issue with the binary test. "It modifies the file without committing, so the safety check correctly refuses. Let me fix the test to follow the same pattern as the other tests." After a while, it satisfied 36 assertions passed across 14 test cases. There was even a full readout of each test and what it verified for quick checking. I asked it to run a demo commit with "commit A containing victim.txt commit B deleting victim.txt checkout A modify victim.txt without committing checkout B." We found a bug. Victim.txt was modified and uncommitted, yet the checkout succeeded. Uncommitted changes were silently destroyed, and the file was deleted despite having modifications. Once the model was satisfied with the fix, I asked it to "add a regression test for the modified-then-deleted checkout case, rerun the full suite, and update DEVLOG.md with the failure and fix. Apply the fix for the bug." It carried everything out well enough but started to stumble with follow-up commands. I finally managed to correct its course with a carefully curated prompt on _read_object(), tree contents not being schema validated, symlinks not handled explicitly, and the devlog being treated as more of a design and test plan rather than the actual journal. All were addressed in the follow-up response. We finally had a Git that worked rather well in testing. So I created a folder and had a play with what was created in less than an hour. It worked just fine with commits, edits, and then some But would I use this over Git? Probably not. I downloaded the tinyvcs.py Qwen created in Open Terminal and moved it to a new "git" folder in my home directory. Through the power of Python scripting, I ran the script to create a .tinyvcs folder within the project test directory, and we were ready to rock and roll. A quick file creation and commit test was smooth, as was creating a new file after a slight filename misspelling. Updating and committing changes to existing files also worked. It was slightly irritating as I wanted to spot something amiss. I wanted to be hit by a Python error when attempting to call a function. I wanted to see missing commits in the log, but no, everything was present and accounted for. It's not perfect, however. What Qwen created was akin to a very early version of Git. We do have a lot going for tinyvcs, including content-addressed objects, SHA-based IDs, blobs for file contents, and tree objects for snapshots, but we don't yet have tags, remotes, branches, diff, merging, and even ignore rules. Updating a file with the Qwen-created Git test. This is probably something I could have gotten the local model to add with a few more prompts and some testing, but for a small project and proof of concept, this is something that works surprisingly well and borrows heavily from what Linus would have produced in the early days of Git. It's also a great example of what can be created with models today. Even models like the Qwen agent I chose through Open WebUI can come up with a working concept with a little guidance. Open WebUI One of the best ways to interact with locally hosted AI models on the home network.