Why Git is called Git

Linus Torvalds: "I am an egotistical bastard, and I name all my projects after myself." Photo: LF Asia, LC3 2018, CC BY 3.0.

The version-control system that now sits under almost every software project on earth is named after an insult its own author applied to himself. "Git" is British slang for an unpleasant, contemptible, or annoying person, and when Linus Torvalds was asked why he picked it, his answer was characteristically unsentimental: "I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git'." The line is quoted in Git's own Wikipedia article and has been repeated so many times it has hardened into canon. What is more interesting than the joke is the two-week emergency that produced the thing the joke names — a deliberate, sleeves-up rebuild of distributed version control written under pressure because the tool the Linux kernel had been using suddenly became unavailable.

The BitKeeper problem

From 2002, the Linux kernel was developed using BitKeeper, a proprietary distributed version-control system made by Larry McVoy's company BitMover. Torvalds had resisted version control for years — the early kernel was managed with tarballs and patches mailed around — but BitKeeper's distributed model fit the kernel's distributed development, and McVoy granted the kernel community a free-of-charge licence to use it. The arrangement was always uneasy. A large open-source project was depending on a closed-source tool, and a meaningful share of the kernel developer base objected on principle.

The arrangement collapsed in April 2005. McVoy revoked the free licence after alleging that Andrew Tridgell — the Samba author — had reverse-engineered BitKeeper's wire protocol to build a free interoperating client called SourcePuller. The technical details of who did what are still argued over, but the practical outcome was immediate: the kernel needed a new version-control system, and there was nothing off the shelf that met Torvalds' requirements. The same fallout, incidentally, prompted Matt Mackall to start Mercurial at almost exactly the same moment — two distributed VCS projects born from one licensing dispute.

Two weeks in April

Torvalds set three hard requirements, all of them reactions to tools he disliked. He wanted to avoid everything he hated about CVS, he wanted a distributed BitKeeper-like workflow, and he wanted very strong safeguards against corruption — both accidental and malicious — which is why Git content-addresses everything by SHА hash. He also wanted it fast: the design target was that operations on the entire kernel tree should feel instant.

The timeline is genuinely compressed. Development began on 3 April 2005. Torvalds announced the project on 6 April. Git became self-hosting — capable of managing its own source — on 7 April, with a first commit whose message reads, in full, "Initial revision of 'git', the information manager from hell." By 16 June Git was managing the kernel 2.6.12 release. The whole bootstrap, from nothing to running the largest collaborative software project in the world, took roughly two weeks of one person's effort. On 26 July 2005 Torvalds handed maintenance to Junio Hamano, who has run the project ever since.

It is worth being precise about what Torvalds built and what he did not. The first version of Git was closer to a set of low-level plumbing tools — a content-addressable filesystem with a thin layer of commands — than the polished porcelain most engineers use today. The friendly command surface (git commit, git checkout, branch handling that a human can reason about) was largely Hamano's and the wider community's work over the following years. Torvalds built the object model; the usability came later.

The name, and the jokes around it

"Git" as British insult is the load-bearing explanation, and Torvalds confirmed it directly. But the project's own documentation has never been able to resist embroidering the point. The Git README has carried a list of tongue-in-cheek interpretations since the early days, offering the reader several things "git" might stand for depending on mood:

• a random three-letter combination that is pronounceable and not already used by any common Unix command;
• "stupid, contemptible and despicable" — take your pick from the slang dictionary;
• "global information tracker," for when you are in a good mood and it is actually working for you;
• "goddamn idiotic truckload of [expletive]," for when it breaks.

The man page itself, deadpan, describes Git as "the stupid content tracker." None of these are the real etymology — they are backronyms, retrofitted expansions of an existing word, the same species of joke that gave "daemon" its fake "Disk And Execution Monitor" expansion. (More on that in where the word 'daemon' comes from.) The difference is that Git's backronyms were authored by the project from day one as a joke, rather than mistaken later for fact.

This is a recurring pattern in the naming of foundational tools. The thing gets a short, blunt, slightly self-deprecating name, and a folk-etymology industry grows up around it afterwards. Grep is an acronym that became a verb. Docker is a metaphor that spawned an entire maritime ecosystem. Git is an insult that the author applied to himself, dressed up afterwards with a menu of meanings.

The "stupid content tracker" was the point

There is a temptation to read the self-deprecation as false modesty, and it is worth resisting. Torvalds genuinely did not consider Git a grand design achievement at the time — in interviews around the twentieth anniversary in 2025 he said version control was never something he was personally interested in; he built Git because he needed it and nothing else would do, then handed it off as soon as it was stable.

The "stupid content tracker" framing reflects a real architectural decision. Git's core is intentionally dumb: it stores snapshots of content, addressed by hash, and almost everything users think of as a Git "feature" — branches, tags, the staging area, the entire notion of history — is a thin layer of references and metadata on top of that content-addressed store. The simplicity of the object model is exactly why Git scaled to projects its author never imagined. The cleverness is in what was left out of the core, not what was put in. The blunt name fits a blunt, durable design.

The plumbing-and-porcelain split

A detail that the "wrote it in two weeks" framing tends to flatten: what Torvalds actually shipped in April 2005 was not the Git that engineers use today. The early tool exposed its internals directly. To make a commit you would manually write a tree object, hash it, write a commit object pointing at it, and update a ref by hand — operations now hidden behind a single git commit. The community came to describe this as the split between plumbing (the low-level, scriptable commands that manipulate the object store) and porcelain (the high-level, human-facing commands layered on top). The terminology is still used in Git's own documentation, and it is a faithful description of how the system was built: a robust, dumb storage engine first, with the comfortable interface accreting on top over the following years.

This ordering is the opposite of how most software is designed, where the user-facing interface is specified first and the storage is an implementation detail. Git was built storage-first, which is why its data model is so stable and its command surface was, for years, so famously hostile to newcomers. The object store has barely changed since 2005. The porcelain is still being refined two decades later — git switch and git restore, added in 2019, exist specifically to untangle the overloaded git checkout that the early porcelain saddled everyone with.

Why the insult stuck

Torvalds has a documented history of picking names that are either self-referential or faintly hostile. "Linux" he initially wanted to call "Freax"; the name "Linux" was pushed by Ari Lemmke, who administered the FTP server where it was first uploaded. By the time of Git, Torvalds had leaned fully into the self-naming bit, which is why the egotistical-bastard line lands as a joke rather than a boast — everyone already knew "Linux" was named after him.

The insult stuck for the same reason most good tool names stick: it is short, it is pronounceable, it does not collide with an existing Unix command, and it is memorable in a way a committee-approved name never is. A version-control system called, say, "Distributed Content Manager" would have been forgotten the moment a better acronym came along. "Git" is impossible to forget, partly because the first time most people hear the etymology they assume it must be a backronym — and then learn that the boring, rude, monosyllabic explanation is the true one.

A short close

Git is named after a British insult, applied by its author to himself, as a joke about his own ego. The README's list of grander meanings is a deliberate backronym joke layered on top, not a competing origin story. Underneath the self-deprecation is the more impressive fact: a distributed version-control system robust enough to run the Linux kernel, bootstrapped in about two weeks in April 2005 in direct response to a licensing dispute, by someone who did not even find the problem domain interesting. The name is a throwaway. The thing it names is the substrate under nearly all modern software development. That mismatch — trivial name, foundational tool — is the most Linus Torvalds thing about the whole story.