iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Linus Torvalds said the writing took about 10 days before he could use Git for Linux kernel work—but that was not the whole project. He had spent roughly four months thinking through the problem and design first. That makes a one-prompt attempt to build a Git-like tool an intriguing contrast, not a like-for-like comparison: a prompt can produce code quickly, but the result still has to prove its scope, correctness, and usefulness.
Did Linus Torvalds really write Git in 10 days?
That is Torvalds’s description of the implementation period up to a practical milestone: when he began using Git for kernel work. In a 2025 interview marking Git’s 20th anniversary, he said, “the writing part was maybe 10 days until I started using Git for the kernel,” adding that there had been “a lot of mental going over what the ideas should be.” He estimated that he had thought about the problem and design for about four months before he started writing. GitHub’s interview with Torvalds is the source of that retrospective account.
So “Git in 10 days” describes the time to an early working tool for a demanding real-world workflow—not the full time spent conceiving, refining, and developing Git. Git’s first commit was made on April 7, 2005, and Torvalds said the early project became self-hosting quickly. The date and milestone do not mean Git arrived as the mature version-control system people use today.
Free tools Windows power users keep installed
One-click scans. No signup required.
Why did Torvalds build Git?
The Linux kernel community needed a distributed source-control system after BitKeeper, which Torvalds had been using, became unusable amid licensing and community conflict. He considered the available alternatives inadequate for his needs, so he set out to build a replacement that could handle kernel development efficiently without simply reproducing BitKeeper’s design. The background is covered in the 2015 Linux.com interview with Torvalds and revisited in the 2025 anniversary interview.
#1 Best Overall
Torvalds has described the central challenge as the design and organization of the data, not merely typing code quickly. In the Linux.com interview, he said, “The trick wasn’t really so much the coding but coming up with how it organizes the data.” Performance and stability mattered because Git had to serve the Linux kernel’s scale and workflow. In the 2025 interview, he also described hashes as a way to detect corruption and said that complexity accumulated in the details and user interface around a small set of fundamental low-level ideas.
What does a one-prompt Git-like build show?
I asked my local LLM to build something similar to Git with one prompt. That makes for a useful experiment in how quickly a model can produce a version-control prototype. It does not, by itself, show that the model recreated Git or produced software that is safe to rely on. Torvalds’s historical account is a retrospective interview; it does not independently verify this experiment’s model, prompt, generated code, tests, or outcome.
To make the comparison meaningful, an account of the prototype needs to show what it actually does and how it was evaluated. The relevant questions are more specific than “Did it generate code?”:
- Time accounting: How long did it take to get the first output, and how much time went into shaping the prompt, debugging, and testing? A prompt-to-output time is not directly comparable to implementation time after months of design work.
- Feature scope: Which operations does the project support, such as creating a repository, recording changes, viewing history, branching, merging, or recovering from errors? List only what was implemented and demonstrated.
- Correctness and data integrity: What tests were run, including cases involving conflicting changes, interrupted writes, malformed data, or attempted recovery? A repository tool that loses or corrupts work is not a usable substitute.
- Performance and scale: What repository size and workload were tested, and how did the tool behave? A tiny demonstration repository cannot establish suitability for kernel-scale development.
- Usability: Can someone use the tool from its documentation and commands, without relying on assumptions left unstated in the original prompt?
- Maintenance: Is the design understandable enough to support fixes, new features, and other users?
Without those results, the fair conclusion is limited: one prompt can be used to ask a local LLM for a Git-like prototype. Whether that prototype works well, how complete it is, and how it compares with Git depend on evidence about the generated project—not on the speed of the initial request.
How Git’s 10-day milestone compares with an LLM prompt
The two efforts answer different questions. Torvalds was trying to solve a concrete source-control problem for Linux kernel development and reached a point where he could use Git in that work. A one-prompt build begins with a request and may produce an initial implementation, but that output still needs to be examined against an intended use case. No common benchmark in the cited accounts measures the two efforts side by side.
There is also a difference in what “finished” means. Torvalds said Git’s first code was relatively small and that he added capabilities over time. In the 2025 interview, he characterized his own effort across Git’s 20-year history as about four months, crediting Junio Hamano and other contributors for much of the rest. That is his retrospective characterization, not a measured time log. Git’s subsequent life as a community project is part of the story; an initial generated codebase alone cannot establish comparable longevity or maintainability.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What Git’s history means for AI coding agents
AI coding agents make Git workflow more relevant, not less. GitHub’s 2025 discussion of Git’s future notes practical questions around agent-created changes, including meaningful commit messages and context-aware amending, squashing, and rebasing. Those are workflow concerns: they do not show that an agent-generated version-control system is equivalent to Git, or validate any particular local-model experiment. GitHub’s article on Git’s next 20 years discusses that broader ecosystem context.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →For someone learning Git, Torvalds has acknowledged that it can overwhelm beginners and recommended starting with basic operations. Understanding the ordinary workflow—recording changes, inspecting history, and working with branches—also gives a useful basis for judging what a generated tool can and cannot do.
Quick Recap
Best Value
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
