10 Years of Git: An Interview With Linus Torvalds

LibbyMC writes Git will celebrate its 10-year anniversary tomorrow. To celebrate this milestone, Linus shares the behind-the-scenes story of Git and tells us what he thinks of the project and its impact on software development. From the article: "Ten years ago this week, the Linux kernel community faced a daunting challenge: They could no longer use their revision control system BitKeeper and no other Software Configuration Management (SCMs) met their needs for a distributed system. Linus Torvalds, the creator of Linux, took the challenge into his own hands and disappeared over the weekend to emerge the following week with Git. Today Git is used for thousands of projects and has ushered in a new level of social coding among programmers."

Comments

Re:And yet, no one understands Git.

[angel'o'sphere]

Use a GUI frontend like SourceTree from Atlassian, there is not much different in Git versus other systems.
The difference only shows when you actually look into the file layout of a git repository ... and who is doing stuff like this (besides me) anyway?

Re:And yet, no one understands Git.

[Anonymous Coward]

OK. Step 1 - download git. Right, done. Step 2 - create a repository What's a repository and why would I want one? Step 3 - clone a repository How does that help me backing up my stuff? Step 4 - workflow Cool! Its a plate-of-noodles! Step 5 - add and commit. Ah, what step 3 should have been. Why 2 steps, why not 1 "doit" step? And a message - how do I disable that? I don't want to have to type a message for every pissant change. Step 6 - push changes. Again, why not 1 "doit" step? Step 7 - branching. At last, something useful. Simplify the syntax, though. Step 8 - merging. Why the git add step? Step 9 - tagging. Fairy Nuff. Step 10 - logs Ditto. Step 11 - oopsies Ok. That's what I'll need most. Step 12 - GUI etc. Nope, cmdline only, thanks. OK, some basic concepts that just seem overly complicated and un-needed, what circumstances are these needed for that they can't be bypassed?

this is really a story about..

[Anonymous Coward]

how bitkeeper fucked up and was swiftly relegated to irrelevance... you have to wonder how many of these are even still using bk......

Re:And yet, no one understands Git.

[Yunzil]

You have to understand the data-structure, how files, directories and commits are all content-addressable objects. The linkage of the commits by means of their id's must be understood.

See, here's the thing. Why should I have to understand internal data structures in order to use a piece of software? Imagine if you made a word processor and people found it difficult to understand, and you said, "It's easy once you understand that the words in the text are stored in a hash map along with a structure with various flags that encode things like whether it's italic or not." People would look at you funny and go back to using Word.

Command non-orthogonality is its weak point

[Traf-O-Data-Hater]

Like others, I both love git and hate it. The bit I dislike the most is the inconsistency in commands and their opposites.
For instance, it is easy to add files to staging:
git add .
Oops! A bunch of other things got added, because I'm a newbie and haven't yet tuned my .gitconfig. Fine, I'm still learning.
OK, have a guess at undoing it:
git unadd
wtf?...nope..
Frustrating searching to find that git reset is really unadd. Yeah, I could guess that! not.
And that's the crux of it. Sure you can add git aliases, but an xxx/unxxx pattern could have been built in right from the (ahem) git-go for any sensible command. Git commit/uncommit... merge/unmerge... etc etc.

And the great thing about git: Linus realised disk space was becoming to cheap to meter. Why bother crunching a delta on something when it was easier to just store compressed blobs. Thus the advantage of simple, fast and cheap (pick any three) branching.

Git is its own worst enemy

[Foresto]

Git is its own worst enemy

Sigh... Git. Ten years later, and it's still making people suffer with its unforgivably awful user interface. Seriously. I like the command line, and git is my primary version control system, but git's UI is the single most user-hostile example of human-computer interaction that I have had the misfortune to encounter in years. Maybe decades.

Git's command structure is a train wreck of inconsistencies, some of its most important terminology is worse than worthless, and its man pages and built-in help text are idiotically obtuse. I have been following its development closely enough to understand how it got this way. A lot of it has to do with placeholder terms that were never updated, synonyms that were never reconciled, features that were grafted onto existing commands and never properly organized, and its origin as a set of low-level components rather than a tool intended for humans. In other words, a pattern of evolution much like any other software, except for one thing: Even after years of being relatively stable, its mantainers still haven't addressed its glaring usability problems.

These aren't just minor warts that only affect a few people, either. There are countless articles, blog posts, and forum threads expressing frustration with git and detailing specific improvements that could transform it from a usability nightmare to an elegant piece of work. Sadly, the maintainers either ignore them or respond with some half-witted reason to resist change. Frankly, I am embarrassed to see my fellow software developers failing so miserably to recognize the importance of usability, and failing to fix it.

What is the cache? It's a place where you're expected to manually arrange your data before you commit it. Does it function like a person would expect a cache to function? No, but we call it that anyway. What is the index? It's the same thing. Does it function like a person would expect an index to function? No, but we call it that anyway. You're referring to the same thing in both cases? Yes, for the most part. Does it function like anything that might be familiar to anyone? Yes, it's essentially a staging area. Why don't you call it a staging area? We do, but only in the minority of cases. You mean you have three names for the same thing, and the most accurate name is the one that you use the least? Yes. Why? Because the meaningful name might be harder to translate into other languages. So you deliberately use a confusing variety of misleading names when writing in English, the single most widely used language in computer science, because one of your translators didn't want to describe a staging area in another language? Yes. Well, that's probably okay, because this thing is probably some obscure piece of git that most people don't have to use, right? No, it's actually one of git's most distinguishing features, and interacting with it is absolutely required in order to use git. I see.

Newcomers shouldn't have to be encouraged to "take the time to learn git." It should be easy. A programmer familiar with version control systems should be able to pick up a new one in five minutes, and find the answer to most intermediate-to-advanced problems in maybe ten or fifteen. They should be able to walk away for a month or two, come back, and still remember how to use it. That doesn't generally happen with git. One has to invest quite a bit of time and patience to confidently use anything beyond its most basic operations without screwing something up, and stay in practice with it, or else end up having to learn most of it all over again.

The ridiculous thing is that it doesn't have to be this way. Mercurial is real-world proof of that.

I hate git for these reasons. It's a cantankerous bastard of a tool that will just as soon kneecap you as handle your data. I only use it because of github (which is brilliant, by the way.) If you want to see an example of how version control should be done, get to know mercurial. Its internal de