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.
Why use a parable when you can use history instead?
Some simple pictures or diagrams would make it perfect.
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.
I'm fine with the command-line interface, but for sake of argument, I'm curious what you think the UI should be like.
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.
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!)
(I know about the command.)