Linus Torvalds Creates Git in 10 Days After a Licensing Dispute

On April 7, 2005, Linus Torvalds created Git’s first self-hosting commit. Within roughly ten days the tool was usable for Linux kernel work. The compressed origin story is true in that operational sense, but Git was not a polished modern product written from no prior thought in ten days: Torvalds had spent months considering source-management requirements, and years of BitKeeper experience shaped the design.

The trigger was the breakdown of a controversial free-of-charge arrangement for a proprietary tool.

BitKeeper had solved real kernel-scale problems

From 2002, many kernel maintainers used BitKeeper, a distributed source-control system from BitMover. It handled branching/merging and decentralized maintainer trees better than then-common CVS/Subversion workflows. BitMover allowed free use for qualifying open-source developers while retaining a proprietary license.

Some kernel developers objected on principle and because license terms constrained interoperability/competing-tool work. Torvalds accepted the pragmatic performance advantage while hoping for an open alternative able to meet the kernel’s scale.

The relationship ended amid a protocol dispute

In 2005, Andrew Tridgell investigated BitKeeper’s network behavior to improve interoperability/archive access. BitMover viewed the work as reverse engineering prohibited by its free-use terms; Tridgell and supporters disputed characterizations of what he had done. Negotiations failed, and BitKeeper’s free-of-charge availability to the kernel community ended.

It is more accurate to call this a licensing/interoperability dispute with conflicting accounts than to say one party simply “stole BitKeeper” or that all kernel developers were formally revoked on one instant.

Torvalds designed for content and distributed trust

The new system prioritized speed, simple data structures, non-linear development, full distribution and kernel-sized repositories. Git stores content-addressed objects and builds commits/trees from hashes, making corruption or unintended content change detectable through object identity.

Cryptographic hashes do not automatically authenticate authors or make repository content safe. Signing, review and trusted distribution remain separate. Git’s original SHA-1 design later required a controlled transition path because collision research advanced.

April 7 is the verifiable first-commit date

The root Git commit e83c5163 carries April 7, 2005 author/committer timing and an initial README describing an “information manager from hell.” Enough plumbing existed for Git to record itself. That is a stronger artifact than a rounded anecdote about when coding “began.”

By Torvalds’ 2025 retrospective, about ten days describes reaching kernel-usable capability, not total design conception. The first version exposed low-level commands and was difficult compared with today’s porcelain.

The kernel transition happened over weeks

Kernel history was imported/managed and the project moved to Git during the following weeks. Linux 2.6.12, released June 17, 2005, was the first mainline release produced after the transition. Existing patch email/review and maintainer hierarchy remained; Git managed commits/branches/merges rather than replacing review with a forge.

This hybrid persists: patches are discussed over mailing lists, subsystem maintainers integrate Git branches, and Torvalds merges into mainline.

Junio Hamano turned the prototype into a project

Torvalds concentrated on the kernel once Git met his immediate need. Junio C Hamano became maintainer in July 2005 and led the project through Git 1.0 in December 2005 and its long subsequent maturation.

Attributing all later Git UX, protocols, security work and portability to the first ten days erases thousands of later contributors. The initial architecture mattered because it left room for porcelain, hosting and workflows to grow.

Distributed did not mean ungoverned

Every clone contains history/objects, and branches can be exchanged without one server. Projects still choose authoritative refs, maintainers, review rules, signing policy, CI and release processes. GitHub/GitLab appeared later as collaboration/hosting layers; Git itself does not require them.

The kernel’s use demonstrates both halves: technically distributed repositories, socially defined maintainer trees.

The lesson was infrastructure exit risk

The kernel depended on a proprietary tool supplied under revocable favorable terms. When stakeholder/license goals diverged, the project needed an exit under intense time pressure. Git’s creation converted that dependency into an open tool tailored to the workload.

Organizations should inventory source/build/signing/CI dependencies, export formats, license/price-change risk, credentials and recovery drills before a vendor dispute. Very few teams can build a secure replacement in ten days.

The artifact matters more than the legend

The strongest chronology is: BitKeeper use from 2002; relationship breakdown in early 2005; Git root commit April 7; kernel-capable workflow in roughly ten days; 2.6.12 released from the new process in June; maintenance handed to Hamano in July; Git 1.0 in December.

That sequence preserves the remarkable speed without claiming a complete modern ecosystem appeared instantly or reducing a complex dispute to one villain.

Related:

Sources: