A few issues where "The Git Parable" diverges from real git history and real git behavior:

1. From the beginning it was known that simple numbering system for snapshot (commit) names would not work without constant access to single central 'numbering authority'. So the history of git is without this meandering; on the other hand git had example in Monotone, existing distributed version control system. But this is certainly minor issue.

2. The staging area was not created to be able to split changes into more than one commit or keep dirty files in working area (with changes which do not go into snapshot). This is side benefit, and something you should not abuse. The main reason behind staging area is merging. This is IMHO fairly important didactic issue.

3. Git calculates SHA1 of uncompressed object, and then uzes zlib compression on it, not vice versa as it is said at the end of "The Git Parable". It used to be the way described (first compress, then SHA1 of compressed contents) for a very short time and was abandoned; current way allow to transparently improve compression.

These points are all true, though I'd like to point out that the post is not intended to be an accurate description of history or implementation. It is meant as a teaching tool, hence the label "parable."

Even taking into account the fact that its is "parable" and not recount of the history of Git (which you can find in some detail on Git Wiki, by the way), one point stays: it is IMVHO bad practice to explain staging area in the terms of splitting changes into more than one commit and/or comitting with dity tree, i.e. with some changes uncomitted. Staging area main strength (besides being explicit version of other SCMs implicit to-be-added area) is dealing with CONFLICTED MERGE, and that is how it should be explained, I think.

This is a wonderful way to teach. Inspired.

I guess. But in this particular case, the early development of git looks almost exactly like what's described. You can go back and read Linus's early descriptions and the traffic in the early days on the mailing list and see the design as it actually unfolded.

Why use a parable when you can use history instead?

It takes a lot more time and effort to sift through mountains of emails than it does to read a single post whose sole purpose is to distill all that information into one, easy to consume piece.

Here's a couple of interesting posts Linus wrote a few years ago summarizing some aspects of Git's history and design.

http://mid.gmane.org/[email protected]... http://mid.gmane.org/[email protected]...

This is very nice. It has helped to make the storage mechanism in particular clearer to me, but also some of the nomenclature used when working with Git — tree, blob etc.

Enjoyed reading, followed along for most of it, but as the post wound on it became increasingly more dense to make sense of.

Some simple pictures or diagrams would make it perfect.

Teaching people more than a few commands would be made a lot easier if there was a proper GUI for git. I find the current GUI to be severely lacking.

Which gui? TortoiseGit looks like it is making progress: http://code.google.com/p/tortoisegit/

The Porcelain command line interface is quite nice itself. Gitk isn't pretty (not Apple-style pretty at least) but perfectly functional for viewing logs.

GitX is pretty awesome for Mac. http://gitx.frim.nl/

Could you be more specific?

I'm fine with the command-line interface, but for sake of argument, I'm curious what you think the UI should be like.

It would be nice if the interface could walk you through those first few steps you need to take when you're getting introduced to a version control system. Some explanation would be nice. A "Pull" function would also be handy, not to mention some graphics to show where you are in the tree.

The biggest thing that would be needed, however, are some better error messages. Yes, "non fast-forward" is true and descriptive, but a little short for beginners. They are left thinking things like "What is a fast-forward? Why isn't it a fast-forward? Can you just make it work?".

I've looked into changing those error messages (and maybe making the system more internationalized) but they are hard-coded in git's source code, and are not easy to track down.

You're right. There's remote->fetch, but no pull. Weird.

The interface of git seems to assume that you're familiar with the underlying concepts. The official docs and tutorials are pretty good nowadays, but I can see how the interface itself really doesn't give you many clues. (I was already familiar with hg when I started using git, so I picked it up quite quickly.)

Coming up with a newbie-friendly interface has probably been a much, much lower priority than getting the underlying system working well, which is pretty typical of Unix culture. Writing good GUIs can be quite hard, and moreover, takes a very different skill set than most programming does. (GUIs like this (http://www.ok-cancel.com/comic/4.html) are ... not helpful.)

> The biggest thing that would be needed, however, are some better error messages.

While I emphatically agree with you, in all fairness, everything needs better error messages. (Have you ever used OCaml? Yeesh!)

No git pull?

http://www.kernel.org/pub/software/scm/git/docs/git-pull.htm...

He means in the gui. There's a menu item for fetch under remote, but no pull. That seems kind of arbitrary.

(I know about the command.)

What's wrong with "git gui" and "gitk"? Built in and adequate. Esp. gitk...

very awesome, should be a part of the official documentation, because it provides a great introduction to the concepts, and the thinking behind them

truely awesome article