Celebrating 15 years of Git: An interview with Git maintainer Junio Hamano

Fifteen years in, Git's maintainer reflects on its past and future

To mark Git's 15th anniversary, GitHub's Jeff King sat down with Junio Hamano, the project's maintainer since 2005. King, who has contributed to Git since 2006 and worked on Git at GitHub since 2011, joined Hamano for a conversation about the version control system's evolution, the community behind it, and what lies ahead. Both serve on Git's project leadership committee at Software Freedom Conservancy.

A name with a twist

Hamano's first name is pronounced like the Spanish word for the sixth month of the year. As he explains, it isn't actually his name: it's the name of that month in some other language, a detail he says he shares only with people he meets in person.

From tarball to maintainer

Hamano wasn't there at Git's genesis, but he came close. About a week after Linus Torvalds announced an early version on April 7, 2005, Hamano got the tarball and read through the entire codebase in one sitting.

"It was small enough to read in two hours and understand all that was going on in the code," he recalls. "I remember that I was very impressed by the simplicity of the design and the clarity of the code."

His motivations were practical at first. His employer at the time benefited from the Linux kernel project's work, and he saw Git as a way to help Torvalds get back to kernel development sooner. There was never a question of choosing between Git and another system: the goal was simply to support the effort that would let Linus declare victory and return to his primary work.

By the end of July 2005, Torvalds had handed the maintainer role to Hamano, who had earned it through active contribution. The path to that position was forged in an intensely competitive environment. Early Git development was crowded with skilled contributors, many from the Linux kernel community, and features often had multiple competing designs.

"Not only did you need to come up with a well-designed feature that's implemented well, you also needed to present it better than others who may be working on a similar feature," Hamano says.

Favorite features, and one regret

Among the features Hamano was deeply involved in, two stand out: rename and rewrite detection in the diff engine, and blame's ability to follow lines across file boundaries when asked to do so.

But the technical achievements aren't what he prizes most. "What I'm more proud of, as the maintainer, is how our development community came to be, full of great developers from different backgrounds, working for different employers, having different agendas, but still work together to make progress," he says. He also takes pride in the project's habit of writing detailed commit messages, which has made git log genuinely useful for developers.

Asked about his favorite Git-adjacent tool, Hamano answers without hesitation: "tig," the curses-based interface for browsing git log and running git blame.

If he had a magic wand, Hamano would go back to 2005 and warn Torvalds about one design decision: reusing the command line revision parser from git rev-list for git diff. The resulting syntax allows diff A..B, which expresses a comparison between two endpoints as if it were a range. That notation can't easily be removed now, he notes, and it persists even among users who understand why it's logically inconsistent.

Other changes remain possible. The index, for instance, could theoretically be restructured from a flat data structure into a hierarchical one. It would be a disruptive change requiring substantial rework, but unlike the command line syntax, it could be done without breaking end users.

The real meaning of distributed

When Hamano reflects on how Git has changed software development, he downplays the obvious interpretation of distributed version control. Syncing before a flight, working offline, and syncing after landing matters less in a world with ubiquitous connectivity. And while forking is easy, forks eventually need to merge back into the original if collaboration is the goal. Most projects still rely on a central repository with a single, advancing history.

The aspect of distribution that mattered most, in Hamano's view, is the separation between committing and publishing. That separation gives developers room to make private commits as they work and then present their results through a separate polishing phase, using tools like interactive rebase, before anyone else sees the work.

"It helped imperfect (read: all of us humans) programmers pretend as if they were perfect," he says. The process isn't a straight line to a solution, he admits: it's more like stumbling toward the right answer. But developers with good discipline used these tools to look like programmers who never make mistakes, and over time the pretending became real.

Tools alone can't force improvement, and programmers without discipline may not take full advantage of the chance to proofread before publishing. Still, Hamano believes the average quality of software has risen because developers now have an easy way to polish their work before sharing it.

Those interested in following Git development can subscribe to the project's mailing list or browse the repository on GitHub.