Well, that future self is here. A few days ago, I started actually learning Git, and I came across this somewhere: “Git is written in C”. At first I interpreted it as the commands being in C, but a while later I realised it was the actual making of Git that was primarily in C.

And then, there I was, in my rabbit hole, exploring the whys and hows of everything about Git. And you can see the result of the rabbit hole in front of you.

A Quick History

The Relationship between Linux Kernel and BitKeeper

In the early 2000s, the Linux Kernel started using BitKeeper. Larry McVoy (the copyright holder of BitKeeper) allowed the Linux developers to use BitKeeper on one condition: “They couldn’t reverse-engineer or create a competing open-source tool based on BitKeeper”.

The Crisis

In 2005, Larry McVoy, the copyright holder of BitKeeper, claimed that Andrew Tridgell, the creator of Samba, used SourcePuller to reverse-engineer BitKeeper’s protocol. Some sources say he analyzed the network traffic between BitKeeper’s client and server.

BitKeeper saw this as a violation of their agreement and revoked the free access, cutting off the Linux project from BitKeeper.

The Replacement

So, now the Linux Kernel needed a replacement for BitKeeper as soon as possible. At the time, the two of the Source-Code Management Systems were Concurrent Version System (CVS) and Subversion (SVN).

However, neither of them met Linus’s criteria, eliminating all the existing systems. This called for the making of a system that was actually needed, and Git was born.

The Birth of Git

Linus Torvalds started the development of Git on 3rd April 2005, and announced the project on 6th April 2005, with the main development part of Git taking 10 days (so to the ones whose birthdays fall here, do not forget to wish Git too!).

Linus’s Approach

Linus didn’t build an SCM; he built a Content-Addressable filesystem. These were his lines:

In many ways you can just see git as a filesystem—it's content-addressable, and it has a notion of versioning, but I really designed it coming at the problem from the viewpoint of a filesystem person (hey, kernels is what I do), and I actually have absolutely zero interest in creating a traditional SCM system.

His focus was on the snapshot objects, SHA-1 hashing (Secure Hash Algorithm), and fast DAG (directed acyclic graphs) traversals. I remember studying these for the semesters. Haha.

The main goals that Torvalds designed Git for were: [Source: here]

• Speed: Efficient handling of large repositories.

• Distributed Architecture: Every developer has a complete repository copy.

• Data Integrity: Secure tracking of changes.

• Non-linear Development: Strong branching and merging support.

[Further Reading of Git's History [here]]

The Onset Of GitHub

I will be honest, a year ago I thought Git was an extension to GitHub itself, but it turns out to be kind of the other way around.

GitHub emerged as a platform built around Git, making it easier for developers to host, manage, and collaborate on Git repositories. Its development began in 2007 and was launched in 2008.

Photo by Roman Synkevych on Unsplash

A bit unrelated, but I've got to say this.

This mascot you see here was originally created by a graphic designer to sell on iStock, which eventually became GitHub's mascot "Mona," an anthropomorphized "octocat" with five octopus-like arms.

Why C as Starters?

At the time, given how much the languages had evolved, C came out to be a better option. But we could wonder why Linus did not choose C++ instead.

The Git Mailing List Debate

On 5th September 2007, a developer (Dmitry Kakurin) posted to the Git mailing list asking why Git was written in pure C instead of C++.

To this, Linus replied, saying: [A reference: here]

“C++ is a horrible language!”

One of his arguments in an earlier thread was that C++ was limited because of its abstractions at the time, quoting;

“Hides things like memory allocations behind your back”

[It gets a little technical here~ and we are talking about the level of C++ back in 2005]

The general reasoning we could make is that C++ abstractions like the standard template libraries, implicit memory allocations, and complex object models can create a hidden overhead, unstable compilation across platforms, and poor design habits for low-level systems.

Some Inferences

Looking at some of Quora's lines, while they don’t have a direct relation, we could infer something from them. They basically talk about why some foundational libraries and system tools favor C. [You can refer to the Quora discussion here]

C has predictable codepaths and memory overhead, which avoids C++ virtual method table lookups and class metadata. It has direct ABI (Application Binary Interface) stability and standard C linkage without the name-mangling issues common in C++. And C also has compact runtime efficiency framework bloat.

Git Architecture & Linux Kernel Principles

Git's core interacts heavily with the operating system: files, processes, pipes, memory, sockets, and filesystem metadata. C provides direct access to these Unix/POSIX interfaces with relatively little runtime machinery.

Basically, all of this means Git's original problem was fundamentally a low-level systems problem, and C gave Linus direct control over the data structures, memory, files, and processes involved.

The Ecosystem Evolves: Git Reimplemented

Why Reimplement?

As Git became infrastructure rather than merely a command-line tool, developers increasingly wanted Git functionality embedded directly into applications and services.

What does it mean? It means that they exist because different ecosystems wanted Git functionality implemented natively in their own environments.

The Major Ports

Java (JGit):

A Git implementation for the JVM, allowing Java applications to work with Git repositories without depending on the C Git executable.

C-as-a-library (libgit2):

It keeps C but changes the delivery model. Instead of Git primarily being an executable that users invoke, libgit2 provides Git functionality as a library that applications can link against.

Go (Go-Git):

Git implemented directly in Go. Applications written in Go can interact with Git repositories through Go APIs rather than invoking the external Git executable.

Rust (Gitoxide):

This term genuinely sounds like a chemical. Anyways, a Rust-based reimplementation exploring memory safety, performance, and modern systems-programming techniques.

A Fun Nuance

A fun thing I found about Git, which I was definitely not expecting, was the meaning behind its name.

Git is actually a British English slang for an unpleasant or silly person. The man page (manual page) of Git describes it as “the stupid content tracker”.

It came out rather funny and very humane to me when I read this. I can’t mention any further, but if you are interested in getting a laugh at the silliness of humanity, you can give a read [here].

The Takeaway

What started as a simple “Git is written in C” fact somehow led me through a licensing crisis, distributed systems, content-addressable storage, DAGs, and multiple programming languages. And I think that is what makes Git interesting: behind a command as simple as git commit is a history of engineering decisions that still shape how we work with software today.

Sources:

• Wikipedia

• Git

• A GitHub reference of Linus's lines

• An article on Linus’s stance on C++

• The source code of Git

• Some arguments on Git being written in C

• A later discussion on Rust and a reference to Linus’s lines on the 2007 Git Mailing List Debate