Skip to content

Git — Trivia & Interesting Facts

Surprising, historical, and little-known facts about Git.

Linus Torvalds created Git in 10 days

Linus Torvalds began writing Git on April 3, 2005 and had it self-hosting (managing its own source code) by April 7 — just four days later. By April 18, he had multiple branches merging successfully. The entire initial development took roughly 10 days. He created it because BitKeeper revoked the Linux kernel's free license.

The name "Git" is British slang for an unpleasant person

Linus Torvalds has said the name is either a random three-letter combination that wasn't already used by a Unix command, a reference to the British slang term (he called himself "an egotistical bastard" who names projects after himself), or an acronym for "Global Information Tracker" when it works well and "Conditions Damn Information Tracker" when it doesn't.

Git stores snapshots, not diffs

Unlike most version control systems (CVS, SVN, Perforce), Git does not store differences between file versions. Instead, it stores a complete snapshot of every file at each commit. Unchanged files are stored as pointers to previously stored identical content. This design choice is why Git branching is so fast — it's just creating a new pointer.

The SHA-1 hash was chosen for integrity, not security

Git uses SHA-1 hashes to identify every object (commit, tree, blob). Linus chose SHA-1 for data integrity verification, not for cryptographic security. After SHA-1 collision attacks became practical (Google demonstrated one in 2017), Git began transitioning to SHA-256, though the migration has been extremely slow due to backward compatibility.

Git existed for three years before GitHub launched in April 2008. Before GitHub, Git was considered overly complex compared to SVN, and many developers avoided it. GitHub's social features (profiles, followers, pull requests) made Git accessible and fun. By 2011, Git had overtaken SVN as the most popular VCS, largely thanks to GitHub.

The Linux kernel repository has over 1.2 million commits

The Linux kernel Git repository, one of the largest and longest-running Git projects, contains over 1.2 million commits from more than 25,000 contributors. The complete repository with full history is approximately 4 GB. Git was specifically designed to handle repositories of this scale efficiently.

"git bisect" has saved millions of engineering hours

git bisect performs a binary search through commit history to find which commit introduced a bug. It can test 1,000 commits in just 10 steps. Google engineers have estimated that bisect saves thousands of engineering hours per year within Google alone by automating the "which commit broke this?" investigation.

The reflog is Git's secret safety net

The reflog (git reflog) records every change to HEAD and branch tips, even operations like rebase and reset that appear to "rewrite history." Almost any apparently lost commit can be recovered through the reflog for at least 30 days (the default expiry). Many developers don't know this exists until they desperately need it.

Git was not designed for large binary files

Git stores every version of every file, and binary files can't be delta-compressed effectively. A 100MB video file changed 10 times creates 1GB of repository data. This led to Git LFS (Large File Storage), created by GitHub in 2015, which stores large files outside the repository and replaces them with text pointers.

Merge commits vs. rebasing is the longest-running Git debate

Whether to use merge commits (preserving branch history) or rebasing (creating a linear history) has been debated since Git's early days. Linus Torvalds himself uses both: rebasing for local cleanup and merges for integrating feature branches. The Linux kernel's merge strategy creates the most complex merge history of any open-source project.

The staging area (index) was Git's most controversial design decision

Git's staging area — the intermediate step between working directory and commit — was Linus Torvalds' most controversial design decision. Many developers found it confusing and unnecessary. However, it enables powerful workflows like partial commits (git add -p) that are impossible in systems without a staging area.